Re: Review: UNNEST (and other functions) WITH ORDINALITY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY
Date: 2013-07-24 18:00:41
Message-ID: 2136.1374688841@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> On Wed, Jul 24, 2013 at 6:39 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-07-24 18:01:15 Re: Review: UNNEST (and other functions) WITH ORDINALITY
Previous Message Andres Freund 2013-07-24 17:57:42 Re: ilist.h is not useful as-is