>>>>> "Akim" == Akim Demaille <akim@lrde.epita.fr> writes:
>> Yeah, we've definitely found that resolving shift/reduce conflicts
>> via precedence declarations has more potential for surprising
>> side-effects than one would think.
Akim> That's why in recent versions of Bison we also provide a means to
Akim> pure %expect directives on the rules themselves, to be more
Akim> precise about what happens.
It's possibly worth looking at the details of each case where we've run
into problems to see whether there is a better solution.
The main cases I know of are:
1. RANGE UNBOUNDED PRECEDING - this one is actually a defect in the
standard SQL grammar, since UNBOUNDED is a non-reserved keyword and so
it can also appear as a legal <identifier>, and the construct
RANGE <unsigned value specification> PRECEDING allows <identifier> to
appear as a <SQL parameter reference>.
We solve this by giving UNBOUNDED a precedence below PRECEDING.
2. CUBE() - in the SQL spec, GROUP BY does not allow expressions, only
column references, but we allow expressions as an extension. The syntax
GROUP BY CUBE(a,b) is a shorthand for grouping sets, but this is
ambiguous with a function cube(...). (CUBE is also a reserved word in the
spec, but it's an unreserved keyword for us.)
We solve this by giving CUBE (and ROLLUP) precedence below '('.
3. General handling of postfix operator conflicts
The fact that we allow postfix operators means that any sequence which
looks like <expression> <identifier> is ambiguous. This affects the use
of aliases in the SELECT list, and also PRECEDING, FOLLOWING, GENERATED,
and NULL can all follow expressions.
4. Not reserving words that the spec says should be reserved
We avoid reserving PARTITION, RANGE, ROWS, GROUPS by using precedence
hacks.
--
Andrew (irc:RhodiumToad)
