Re: Parsing ambiguity for ORDER BY ... NULLS FIRST/LAST - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Parsing ambiguity for ORDER BY ... NULLS FIRST/LAST
Date
Msg-id 1168076800.3655.83.camel@silverbirch.site
Whole thread Raw
In response to Parsing ambiguity for ORDER BY ... NULLS FIRST/LAST  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parsing ambiguity for ORDER BY ... NULLS FIRST/LAST  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 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.

Since we already have that problem, it seems sensible to go that way
with the NULLS FIRST issue.

Presumably you could put extra grammar rules in to throw errors when you
see FROM NULLS FIRST? Or should we just document it, somewhere?

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: PGCon 2007 Program Committee
Next
From: Peter Eisentraut
Date:
Subject: Re: -f option for pg_dumpall