On Sat, Jun 15, 2013 at 9:37 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Nicholas White escribió:
>
>> For the parsing changes, it seems I can either make RESPECT and IGNORE
>> reserved keywords, or add a lookahead to construct synthetic RESPECT NULLS
>> and IGNORE NULLS keywords. The grammar wouldn't compile if RESPECT and
>> IGNORE were just normal unreserved keywords due to ambiguities after a
>> function definition (e.g. select abs(1) respect; - which is currently a
>> valid statement).
>
> Well, making them reserved keywords is not that great, so maybe the
> lookahead thingy is better. However, this patch introduces the third
> and fourth uses of the "save the lookahead token" pattern in the
> "default" switch cases. Can we refactor that bit somehow, to avoid so
> many duplicates? (For a minute I thought that Andrew Gierth's WITH
> ORDINALITY patch would add another one, but it seems not.)
Making things reserved keywords is painful and I don't like it, but
I've started to become skeptical of shifting the problem to the lexer,
too. Sometimes special case logic in the lexer about token combining
can have surprising consequences in other parts of the grammar. For
example, with a lexer hack, what will happen if someone has a column
named RESPECT and does SELECT ... ORDER BY respect NULLS LAST? I
haven't studied the code in detail so maybe it's fine, but it's
something to think about.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company