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

I wrote:
> 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.

Actually, that way doesn't work, because for example it would fix
select * from with cascaded;
but not
select * from public.with cascaded;
So my suspicion that there'd be too many places to fix seems justified.

> (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.)

This idea might work though. In particular, I think things would work
nicely if we could make the filter return the special symbols like
WITH_CASCADED only when the parser is in a state where such a symbol
could be accepted. This appears to be possible if one is willing to get
intimate enough with the internals of the Bison parser ... but that's
something I'd prefer not to do, as it'd likely tie us to specific Bison
versions to a much greater degree than we are now. At the moment, the
number of cases where word pairs could act unexpectedly is small enough
that I think we can just live with it.

regards, tom lane