On Sat, 2007-01-06 at 13:05 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> 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
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
"Simon Riggs" <[EMAIL PROTECTED]> 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 th
On Fri, 2007-01-05 at 20:19 -0500, Tom Lane wrote:
> 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 nul
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
i
