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

support rename constraint syntax #330

Merged
merged 4 commits into from
Apr 9, 2024
Merged

support rename constraint syntax #330

merged 4 commits into from
Apr 9, 2024

Conversation

jycor
Copy link

@jycor jycor commented Apr 8, 2024

This PR adds syntax support for ALTER TABLE ... RENAME CONSTRAINT [FOREIGN KEY / CHECK]... for foreign key constraints.

@jycor jycor requested a review from zachmu as a code owner April 8, 2024 22:08
Copy link

@fulghum fulghum 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. Just one thought about loosening the FK type restriction to simplify the code a bit.

Comment on lines 2377 to 2383
case *ForeignKeyDefinition:
buf.Myprintf(" rename constraint %s to", node.TableSpec.Constraints[0].Name)
}
switch node.TableSpec.Constraints[1].Details.(type) {
case *ForeignKeyDefinition:
buf.Myprintf(" %s", node.TableSpec.Constraints[1].Name)
}
Copy link

Choose a reason for hiding this comment

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

Do we need to switch on the type of Details? I see that this field will currently always be a ForeignKeyDefinition, but it seems like that would be likely to change in the future if we expanded this to support renaming other constraints, and then this code wouldn't print out the statement correctly anymore. Not a huge deal, since we should catch that in development, but seems like it could be simpler if we just printed out the constraint name without asserting the type.

Comment on lines 4700 to 4701
ddl.TableSpec.AddConstraint(&ConstraintDefinition{Name: string($3), Details: &ForeignKeyDefinition{}})
ddl.TableSpec.AddConstraint(&ConstraintDefinition{Name: string($5), Details: &ForeignKeyDefinition{}})
Copy link

Choose a reason for hiding this comment

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

Similar to the other comment... do we have to supply the Details: &ForeignKeyDefinition{}, or can we just supply the name and let GMS figure out what type it is? Seems like GMS is going to have to validate it anyway, and this syntax seems useful/intuitive to apply to other constraint types eventually, too.

Copy link
Author

Choose a reason for hiding this comment

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

It's probably possible to have GMS determine what kind of constraint it is, but right now gms/sql/planbuilder/ddl.go:convertConstraintDefinition switches on Details to create the right constraint type.

@jycor jycor merged commit eb9306c into main Apr 9, 2024
4 checks passed
@jycor jycor deleted the james/rename branch April 9, 2024 19:28
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