Re: Review: UNNEST (and other functions) WITH ORDINALITY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: UNNEST (and other functions) WITH ORDINALITY
Date
Msg-id 2136.1374688841@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Greg Stark <stark@mit.edu>)
Responses Re: Review: UNNEST (and other functions) WITH ORDINALITY
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Wed, Jul 24, 2013 at 6:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> This patch will introduce, without documentation, a fifth class of
>> keyword.  ORDINALITY will need to be quoted when, and only when, it
>> immediately follows WITH.  Without some change to our deparsing code,
>> this is a dump/restore hazard; and with some such change it's still
>> probably not a good idea.

> Strictly speaking this patc doesn't introduce this fifth class of
> keyword. We already had TIME in that category (and also FIRST and LAST
> in a similar category following NULLS). If we have a solution for WITH
> <keyword> then presumably we would implement it for WITH TIME and WITH
> ORDINALITY at the same time.

It strikes me that we could hack the grammar for CTEs so that it allows
WITH_ORDINALITY and WITH_TIME as the first token, with appropriate
insertion of the proper identifier value.  I'm not sure if there are any
other places where WITH can be followed by a random identifier.

I don't see any workable fix that doesn't involve the funny token, though.
Consider

CREATE VIEW v AS SELECT ... FROM UNNEST(...) WITH ORDINALITY;
CREATE VIEW v AS SELECT ... FROM UNNEST(...) WITH NO DATA;

WITH ORDINALITY really needs to be parsed as part of the FROM clause.
WITH NO DATA really needs to *not* be parsed as part of the FROM clause.
Without looking ahead more than one token, there is absolutely no way
for the grammar to decide if it's got the whole FROM clause or not
at the point where WITH is the next token.  So our choices are to have
two-token lookahead at the lexer level, or to give up on bison and find
something that can implement a parsing algorithm better than LALR(1).
I know which one seems more likely to get done in the foreseeable future.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: ilist.h is not useful as-is
Next
From: Andres Freund
Date:
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY