I've run into an annoying parsing problem while working on the NULLS
FIRST/LAST stuff. It turns out this is ambiguous:
... ORDER BY foo! NULLS ...
It could be that the "!" is a postfix operator and the "NULLS" is the
start of a NULLS FIRST/LAST clause, or it could be that the "!" is an
infix operator and "NULLS" is just a column name. Bison needs to know
which before shifting the "NULLS", since in the former case it has to
reduce <a_expr> at this point.
The problem would go away if we made NULLS a fully reserved word, but
I don't think that's acceptable from a backward-compatibility or
spec-compliance standpoint, considering it's not a keyword at all in any
pre-2003 SQL spec and even in SQL2003 it's a non-reserved keyword.
The only other solution I can see is to make use of the lookahead filter
we already have in filtered_base_yylex() to combine NULLS FIRST and
NULLS LAST into single tokens. This is not an ideal solution: consider
SELECT * FROM nulls first;
This should be considered a valid selection from a relation named "nulls"
with alias "first", but if it's reduced to a single token the grammar
will not see it that way, and will give an error. However, that's a
sufficiently unlikely scenario that maybe we can just ignore it. (It's
possible to work around the case by inserting AS, of course.) We could
probably fix it if we really had to, but it would involve some pretty
ugly coding AFAICS.
BTW: the existing lookahead hack for WITH CASCADED etc. has the
identical problem.
BTW^2: the draft patch Teodor submitted awhile back tries to paper over
this problem by attaching a precedence to "NULLS". But that does not
fix it, it just makes the parser ignore the possibility of infix "!"
in the example. This would result in bizarre behavior anytime someone
tried to use a column named "nulls" in arithmetic expressions.
Thoughts? Anyone see a better way?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
