Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #578: lexer wrongly interprets ".e[0-9]" as a number with scientific notation. #579

Open
wants to merge 6 commits into
base: 5.10.x
Choose a base branch
from

Conversation

niconoe-
Copy link
Contributor

@niconoe- niconoe- commented Sep 3, 2024

@williamdes Here is my fix about #578.

On the first and fourth (because I forgot to move from state 10 to state 4) commits, you can see that token ".e4" is parsed as is and wrongly considered as a number, causing the effect of not being able to detect the "." in "database_name.table_name" as an operator, and cascading to a failure in the parser.

On the second commit, with the fix, you can see ".e4" is no longer a token, but instead "." is a token, and "e4" is another one, which is not a number.

On the third commit… eh, please don't look, I just forgot to remove a debuging stuff 😓

Copy link
Member

@MauricioFauth MauricioFauth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add a test with the example from the issue?

@niconoe-
Copy link
Contributor Author

niconoe- commented Sep 3, 2024

Could you please add a test with the example from the issue?

Yup, that's done 🙂

You can see on parseLoad8.out that the tokens are correctly set up, and the statement is having the expected properties without any error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants