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

Make parser more powerful #10168

Open
wjhuang2016 opened this issue Apr 16, 2019 · 2 comments
Open

Make parser more powerful #10168

wjhuang2016 opened this issue Apr 16, 2019 · 2 comments
Labels
feature/accepted This feature request is accepted by product managers type/feature-request Categorizes issue or PR as related to a new feature.

Comments

@wjhuang2016
Copy link
Member

wjhuang2016 commented Apr 16, 2019

Feature Request

Is your feature request related to a problem? Please describe:

When parsing a statement, we only turn the info into a special AST presently. For example, a select statement will return a selectStmt. However, we may need to get some information in the parser stage which will present in many statements. If we add these information in every AST which needs it, the code can not be concise.

In PostgreSQL, the parser will return a common selectStmt. In MySQL, a struct LEX will save the common info.

Here is a problem that needs a more powerful parser:

In #10004, a concept constItem is introduced. There are some errors in handling non-deterministic functions. For getVar function, if the value is set in the same statement, the function is nondeterministic. Otherwise, it's deterministic.

mysql> select @a:=FROM_UNIXTIME(1), unix_timestamp(@a);
+----------------------+--------------------+
| @a:=FROM_UNIXTIME(1) | unix_timestamp(@a) |
+----------------------+--------------------+
| 1970-01-01 08:00:01  |           1.000000 |
+----------------------+--------------------+
1 row in set, 1 warning (0.00 sec)

mysql> select @a:=FROM_UNIXTIME(1);
+----------------------+
| @a:=FROM_UNIXTIME(1) |
+----------------------+
| 1970-01-01 08:00:01  |
+----------------------+
1 row in set, 1 warning (0.00 sec)

mysql> select unix_timestamp(@a);
+--------------------+
| unix_timestamp(@a) |
+--------------------+
|                  1 |
+--------------------+
1 row in set (0.00 sec)

So we need to know all the set statements in a statement and It's the job of the parser.

Describe the feature you'd like:

Let paser return more infomation

Describe alternatives you've considered:

Let parser return an extra struct?

Teachability, Documentation, Adoption, Migration Strategy:

@ngaut ngaut changed the title Make paser more powerful Make parser more powerful Apr 22, 2019
@zz-jason
Copy link
Member

So we need to know all the set statements in a statement and It's the job of parser.

The parser has already provided the set statement as SetVar function. Could you post the the problems you encountered?

@wjhuang2016
Copy link
Member Author

@zz-jason
Yes, the parser has provided SetVar function, and I want to get all the Set statement in StatementContext. To get it I have to check if there is a SetVar function recursively, and I think it would be great that the parser return a StatementContext like struct.
The problem I encoutered is:

In this command:
mysql> select @a:=FROM_UNIXTIME(1), unix_timestamp(@a);
unix_timestamp should not be a constItem, Because the a is set in the same statement.

In following commands:

select @a:=FROM_UNIXTIME(1);
select unix_timestamp(@a);

unix_timestamp should be a constItem.

To solve the above problem, we need to get all the Set statement in StatementContext

@ghost ghost added the type/feature-request Categorizes issue or PR as related to a new feature. label Jul 23, 2020
@zz-jason zz-jason added the feature/accepted This feature request is accepted by product managers label Jul 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/accepted This feature request is accepted by product managers type/feature-request Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants