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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Review: UNNEST (and other functions) WITH ORDINALITY
Дата
Msg-id 2136.1374688841@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Greg Stark <stark@mit.edu>)
Ответы Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: ilist.h is not useful as-is
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Review: UNNEST (and other functions) WITH ORDINALITY