-
Notifications
You must be signed in to change notification settings - Fork 534
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
Enhancing Trailing Comma Option #1212
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 @MohamedAbdeen21
The idea sounds good and I left a few small comments
I think the biggest concern I have is now there seems to two ways ways of setting trailing comma support -- globally via ParserOptions
and then per dialect
I think if we want to make trailing comma support part of the dialect, we should remove the parser options and just use the dialect trait everywhere
cc @ankrgyl who I think added trailing comma support initially
@@ -157,6 +157,14 @@ pub trait Dialect: Debug + Any { | |||
// return None to fall back to the default behavior | |||
None | |||
} | |||
/// Does the dialect support trailing commas around the query? | |||
fn supports_trailing_commas(&self) -> bool { |
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.
supports_trailing_commas
suggests to me that it is supporting trailing commas everywhere, and supports_projection_trailing_commas
suggests just for projection
If supports_trailing_commas
means just for queries, can you please name it to something more specific?
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.
This option should try to allow trailing commas everywhere. I'm not really following what you mean by "just for queries"
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.
I noticed something while going over the tests, Create table by default allows trailing commas, because it doesn't use the parse_comma_separated
function, which was added later.
Edit: made a temporary change to create table to remove default trailing commas. I say temporary because we probably can rewrite it using parse_comma_separated, but that should be in a follow-up
Pull Request Test Coverage Report for Build 8665267578Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
I think that's completely ok, given that setting it manually overrides the dialect settings. This can give the users flexibility when choosing a dialect for their projects. Keep in mind that trailing comma option is mainly for users who build their queries programmatically.
While I don't like how we have an entire Edit: Adding to the first point, maybe we can extend the flexibility further and add a projection_trailing_comma option? I do have it stashed already, let me know if you think that's a good idea. |
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 again for this PR @MohamedAbdeen21 -- I am sorry it took so long to provide a review. I am quite worried about the change in existing behavior for parsing trailing commas. Can you please fix those and I'll give it another look?
@@ -3354,8 +3354,13 @@ fn parse_create_table_clone() { | |||
|
|||
#[test] | |||
fn parse_create_table_trailing_comma() { | |||
let sql = "CREATE TABLE foo (bar int,)"; | |||
all_dialects().one_statement_parses_to(sql, "CREATE TABLE foo (bar INT)"); | |||
let dialect = TestedDialects { |
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.
I am worried about this change -- I think it means that the trailing comma will no longer be supported by all dialects
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.
Note that all dialects allowed trailing commas, only in create statements, because create statements are parsed by a special function and not by the parse_comma_separated
that actually considers the trailing_commas
option. So that was a bug not a feature; however, as mentioned before, that behavior can be restored using the parsingOptions struct.
PS: I pointed that out in our previous conversation and recommended a follow-up to migrate the create statement to use the general parse_comma_separated
function.
@@ -292,7 +292,7 @@ impl<'a> Parser<'a> { | |||
index: 0, | |||
dialect, | |||
recursion_counter: RecursionCounter::new(DEFAULT_REMAINING_DEPTH), | |||
options: ParserOptions::default(), | |||
options: ParserOptions::new().with_trailing_commas(dialect.supports_trailing_commas()), |
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.
this seems like a good change
@@ -8530,6 +8535,9 @@ impl<'a> Parser<'a> { | |||
with_privileges_keyword: self.parse_keyword(Keyword::PRIVILEGES), | |||
} | |||
} else { | |||
let old_value = self.options.trailing_commas; |
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.
I think this is a change we should discuss in a separate PR as I think it will cause some statements that used to parse to stop working (even if though it is more consistent)
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.
I don't see how that will break any existing statements. The original behavior was that if trailing commas were enabled and a DCL used 'SELECT', the parsing would fail.
This change temporarily ignores the trailing commas option when parsing DCL.
This is definitely not an ideal solution and should have its own PR (and therefore the corresponding issue should not be closed, even tho this was supposed to be the main target issue), but this has to be pushed with the new dialect trait method to pass the tests.
Thanks for the review @alamb, the only breaking change here is the create statements when trailing_commas are not enabled in the parserOptions, which I think was a bug mistaken for a feature. The other change with the DCL doesn't affect the current behavior; if anything, statements that used to fail will now parse. I'm sorry that the PR is addressing multiple points at once, with some of the changes being temporary solutions that require follow-ups. I'll be happy to break this down into 2 different PRs if necessary, but that will be some time as I'm currently working on a different PR. Sorry for making the review difficult, I'll try to make future PRs more focused to ease the review process. |
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.
Thank you @MohamedAbdeen21 and @lovasoa
Sorry for the delay -- I am spread quite thin these days -- though we are discussing a few solutions to improve the situation #1294 |
Fixes
This change addresses #1211 and arrow-datafusion#9949.
Changes included
Added
supports_trailing_commas()
andsupports_projection_trailing_commas()
to theDialect
trait, enablingsupports_projection_trailing_commas()
forBigQuery
andSnowFlake
, andsupports_trailing_commas()
forDuckDb
linkDialect
trait methods to settrailing_comma
parser option when creating new parsers usingParser::new(dialect)
, instead of defaulting tofalse
for all dialects and waiting for the user to set it manually throughParserOptions
.Bug fixes
GRANT
s when trailing commas are enabled #1211, by temporarily disablingtrailing_comma
option when parsingGRANT
statements. *Breaking changes
trailing_comma
is now considered when parsing create statements.* I can use some help regarding changes 3 and 4:
3. The keyword is hard-coded, and only works for projection lists.
4. This may cause issues if the user expects the
GRANT
statement to allow trailing commas.Please, if you have other alternative approaches or suggestions, be sure to share them.
Are these changes tested?
Yes