Thread: searching bison guru - grouping sets implementation
Hello I trying to implement GROUPING SETS feature. But there is basic difference between PostgreSQL and ANSI. Pg allows expressions, ANSI only column reference. I have syntax: group_clause: GROUP_P BY grouping_element_list | /*EMPTY*/ ; grouping_element_list: grouping_element { $$ = list_make1($1); } | grouping_element_list ',' grouping_element { $$ = lappend($1, $3); } ; grouping_element: ordinary_grouping_set { } | ROLLUP '(' ordinary_grouping_set_list ')' { } | CUBE '(' ordinary_grouping_set_list ')' { } | GROUPING SETS '(' grouping_element_list ')' { } | '(' ')' { } ; ordinary_grouping_set: grouping_column_ref { } | '(' grouping_ref_list ')' { } ; grouping_ref_list: grouping_column_ref { } | grouping_ref_list ',' grouping_column_ref { } ; ordinary_grouping_set_list: ordinary_grouping_set { } | ordinary_grouping_set_list ',' ordinary_grouping_set { } ; grouping_column_ref: columnref {} | Iconst {} ; ; this works well, but it is ANSI compliant not pg compliant after change: grouping_column_ref: a_expr {} ; I getting [pavel@localhost parser]$ bison gram.y gram.y: conflicts: 1 shift/reduce, 1 reduce/reduce so I cannot find any way to remove shift/reduce. any ideas?
Attachment
Pavel Stehule wrote: > I trying to implement GROUPING SETS feature. But there is basic > difference between PostgreSQL and ANSI. Pg allows expressions, ANSI > only column reference. The conflict seems to arise from the parenthesis, between these two rules: ordinary_grouping_set: grouping_column_ref { } *** | '(' grouping_ref_list ')' { }; and grouping_column_ref: a_expr {} ; where a_expr can be something like "(foobar)" as well, enclosed in parenthesis. The grammar is ambiguous for something like "SELECT ... GROUP BY (foobar)", bison doesn't know if that should be interpreted as an "'(' grouping_ref_list ')'", whatever that is, or an a_expr. I don't know how that should be resolved, or if it's a genuine ambiguity in the ANSI and PostgreSQL syntax or something that can be fixed with some Bison magic. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > I don't know how that should be resolved, or if it's a genuine ambiguity in the > ANSI and PostgreSQL syntax or something that can be fixed with some Bison > magic. Fwiw I looked into this once already and noted the same conflict: http://article.gmane.org/gmane.comp.db.postgresql.devel.general/83563/match=rollup Tom pointed out that there's more than one way to skin a cat: http://thread.gmane.org/gmane.comp.db.postgresql.devel.cvs/22326/focus=83563 (Oh look at that, he actually used precisely that phrase) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
[Oops sorry -- I used the wrong links for the previous message. Here are the correct links] "Heikki Linnakangas" <heikki@enterprisedb.com> writes: > I don't know how that should be resolved, or if it's a genuine ambiguity in the > ANSI and PostgreSQL syntax or something that can be fixed with some Bison > magic. Fwiw I looked into this once already and noted the same conflict: http://article.gmane.org/gmane.comp.db.postgresql.devel.general/83564 Tom pointed out that there's more than one way to skin a cat: http://article.gmane.org/gmane.comp.db.postgresql.devel.general/83578 (Oh look at that, he actually used precisely that phrase) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!