Re: Parsing ambiguity for ORDER BY ... NULLS FIRST/LAST

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> Presumably you could put extra grammar rules in to throw errors when you
> see FROM NULLS FIRST?

It'll throw an error just fine without any extra rules, because there
won't be any production allowing the NULLS_FIRST pseudo-token there.
You already see this in 8.2:

regression=# select * from with cascaded;
ERROR: syntax error at or near "cascaded"
LINE 1: select * from with cascaded;
^
regression=#

One of the possibilities for fixing it is to add productions that
allow table_ref to expand to NULLS_FIRST, WITH_CASCADED, and the
other two-word pseudo-tokens, and then build the appropriate
relation-with-alias syntax tree out of whole cloth. I find this pretty
ugly though, and I'm not sure that table_ref would be the only place
to fix, so I'm inclined not to do it unless we actually get complaints
from the field. (The other avenue for fixing it would be to try to give
the lookahead filter enough context to know when not to combine the
tokens, but I think that way will probably be unworkably convoluted.)

Oh BTW, there's an interesting bug here: the expected workaround
doesn't work:

regression=# select * from with as cascaded;
ERROR: relation "as" does not exist
regression=#

It should be complaining about "with" not "as". I think that the
lookahead filter is getting out of sync somehow.

regards, tom lane