> In fact, my grammar currently has an obscene
> 20 shift/reduce and 4 reduce/reduce conflicts!
A shift/reduce conflict, IIRC, usually indicates a situation where
the grammar is unambiguous but may be inefficient. Eliminating them
is nice, but not critical.
A R/R conflict, in contrast, is a point where the grammar is ambiguous
and you *must* fix it.
> (Unfortunately, bison isn't very
> helpful: it doesn't provide line-numbers when it warns me about
> the # of conflicts).
Turn on the verbose flag (-v|--verbose). Near the top it should
list the S/R and R/R states. You can then examine the states and
rules and see exactly where the problem is.
Cutting to the chase, the R/R problems are due to "TEMP" and
"TEMPORARY" being both "unreserved keywords" and part of
OptTempTableName. If you comment them out in 'unreserved keywords'
the R/R error goes away but this may introduce errors elsewhere.
What is probably better is to move those tokens someplace else
where there's some context:
into_clause : INTO OptTempTableName
| /* EMPTY */
;
needs to be replaced with something like
into_options : /* EMPTY */
| TEMPORARY
| TEMP
;
into_clause : INTO into_options OptTempTableName
| /* EMPTY */
;
with the corresponding modifiers removed from the OptTempTableName
Unfortunately, when I quickly tested that the number of S/R conflicts
ballooned to 378.
As an aside, is there any reason to treat TEMP and TEMPORARY as two
separate identifiers? It's common practice to have synonyms mapped
to a single identifier in the lexical analyzer, and the grammar itself
looks like it could benefit from some helper rules such as:
temporary
: TEMPORARY { $$ = 1; }
| TEMP { $$ = 1; }
| { $$ = 0; }
;
scope
: GLOBAL { $$ = 1; }
| LOCAL { $$ = 2; }
| { $$ = 0; }
;
something : scope temporary somethingelse { ... }
Bear
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
