Skip to content

Set parser update#6080

Merged
systay merged 5 commits intovitessio:masterfrom
planetscale:set-parser-update
Apr 20, 2020
Merged

Set parser update#6080
systay merged 5 commits intovitessio:masterfrom
planetscale:set-parser-update

Conversation

@harshit-gangal
Copy link
Copy Markdown
Member

No description provided.

systay and others added 5 commits April 19, 2020 23:49
Signed-off-by: Andres Taylor <andres@planetscale.com>
Signed-off-by: Andres Taylor <andres@planetscale.com>
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
Signed-off-by: Andres Taylor <andres@planetscale.com>
@systay systay requested a review from saifalharthi April 20, 2020 08:40
@systay systay merged commit 7589230 into vitessio:master Apr 20, 2020
Copy link
Copy Markdown
Contributor

@sougou sougou left a comment

Choose a reason for hiding this comment

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

Looks good overall. Some nits.

I feel like the Rewriter framework is complex, mainly because of going down vs. coming up, but I assume it's necessary. We avoided the "coming up" for the expression rewriter by using the sub-Rewrite. Not sure if the same thing can be done for this case.

It will require us to chain the rewriters, which is actually an easier pattern to explain and read, and should scale better. I feel like you'll piling on more rewriters as things evolve.


//IsSetStatement takes Statement and returns if the statement is set statement.
func IsSetStatement(stmt Statement) bool {
switch stmt.(type) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

_, ok := stmt.(*Set)
return ok

exp, err := n.normalizeSetExpr(expr)
if err != nil {
n.err = err
return false
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Have you tested this code path? I see a panic in rewriter.go if this returns false.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Yes, it is tested in the unit tests. All cases where we expect errors pass this path. The magic is here: https://github.com/vitessio/vitess/blob/master/go/vt/sqlparser/rewriter_api.go#L40

@systay
Copy link
Copy Markdown
Collaborator

systay commented Apr 21, 2020

I feel like the Rewriter framework is complex, mainly because of going down vs. coming up, but I assume it's necessary. We avoided the "coming up" for the expression rewriter by using the sub-Rewrite. Not sure if the same thing can be done for this case.

I used up vs down a lot when doing semantic checking on the AST in another project - scope is something you do top-down (you push down the scope to the children), whereas typing has to be done bottom-up (you need the types of children to calculate type of the parent).

When I found the rewrite util here https://github.com/golang/tools/blob/master/go/ast/astutil/rewrite.go I thought that it was a nice API and gave me all I wanted.

We can definitely change it if you feel it's too complex - we don't really need that capability today. Maybe tomorrow, but I'm guessing. What I think we need today is:

  • The ability to not descend into a part of the subtree, but to continue with the rest of the tree.
  • Abort tree walking altogether
  • Replace the current node we are looking at

Should we set aside some time and change the rewriter infrastructure? Since it's generated, it should be pretty easy to do.

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.

3 participants