-
Notifications
You must be signed in to change notification settings - Fork 605
Add support for "on delete cascade" column option #170
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! I'd prefer to split c67d667 into a separate PR, so that this PR could be merged independently, and the discussion about evolving our dialect support would be more visible.
As for ON { UPDATE | DELETE } { RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT }
, please see my comments inline...
(Note: ANSI SQL calls a <referential triggered action>
, and here are the Postgres docs.)
2fbdaea
to
79514b7
Compare
I reworked the PR. I will create a new PR for the new dialect option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent, thank you! I have only a few nits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, thanks again!
* Change `Parser { ... }` to store the dialect used: `Parser<'a> { ... dialect: &'a dyn Dialect }` Thanks to @c7hm4r for the initial version of this submitted as part of #170 * Introduce `dialect_of!(parser is SQLiteDialect | GenericDialect)` helper to branch on the dialect's type * Use the new functionality to make `AUTO_INCREMENT` and `AUTOINCREMENT` parsing dialect-dependent. Co-authored-by: Christoph Müller <[email protected]> Co-authored-by: Nickolay Ponomarev <[email protected]>
This introduces some breaking changes.
Is it a good idea to have a lifetime parameter in
Parser
?