Replies: 1 comment 1 reply
-
This is currently intentional because it requires additional context to know if it should be a sign as opposed to an operator, when parsing at the token layer. Consider "SELECT 1 -123.45". It's easier to handle it as always an operator, with an implicit "0" preceeding. A statement level parser that is keeping context and has additional parsing rules based on the preceeding context is really the layer that needs to make the translation. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi Bruce,
I just noticed that for any negative value after parsing, the sign got separated from the number value.
Given the following two test cases:
SELECT -123.45;
SELECT DATEADD(year, -10, '2017/08/25') AS DateAdd;
The results I got after parsing
Start...
Statement 1: SELECT - 123.45
Token type: Keyword Text: SELECT
Token type: Operator Text: -
Token type: NumericLiteral Text: 123.45
Start...
Statement 1: SELECT DATEADD ( year , - 10 , '2017/08/25' ) AS DateAdd
Token type: Keyword Text: SELECT
Token type: SystemIdentifier Text: DATEADD
Token type: Character Text: (
Token type: SystemIdentifier Text: year
Token type: Character Text: ,
Token type: Operator Text: -
Token type: NumericLiteral Text: 10
Token type: Character Text: ,
Token type: StringLiteral Text: '2017/08/25'
Token type: Character Text: )
Token type: Keyword Text: AS
Token type: SystemIdentifier Text: DateAdd
Noticed that the negative sign "-" was parsed as an operator. In these cases, should the sign be part of the NumericLiteral?
The above results were produced using the latest build.
Regards
Paul
Beta Was this translation helpful? Give feedback.
All reactions