Re: [HACKERS] parser dilemma

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zoltan Boszormenyi <zb(at)cybertec(dot)at>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, List pgsql-patches <pgsql-patches(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: [HACKERS] parser dilemma
Date: 2007-04-21 23:21:10
Message-ID: 13680.1177197670@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Zoltan Boszormenyi <zb(at)cybertec(dot)at> writes:
> Tom Lane rta:
>> [ a bit alarmed... ] This is only going to be an acceptable solution
>> if you can explain *exactly why* it works. The general story with
>> associativity/precedence declarations is that you are making bison
>> resolve ambiguous situations in particular ways.

> So, before marking, bison was able to do this association:
>
> colname coltype ( DEFAULT 5! GENERATED ) ALWAYS ...
>
> after marking GENERATED as %right, it can only do this:
>
> colname coltype DEFAULT 5! ( GENERATED ALWAYS ... )
>
> With marking GENERATED as %nonassoc, it cannot do either,
> leaving the only option for associating DEFAULT as:
>
> colname coltype (DEFAULT 5!) (GENERATED) ALWAYS ...

Well, as I was saying, safe use of these options requires knowing
exactly what you're doing, and evidently you don't :-(. The above
explanation has got about nothing to do with what Bison really does
with associativity/precedence; you need to read the precedence pages
in the Bison manual.

The reason your patch makes it appear to work is not associativity;
it is that you assigned GENERATED a precedence lower than POSTFIXOP.
This means that when Bison is considering whether to reduce a
postfix-operator rule, and GENERATED is the next token, it'll choose
to reduce. The problem is that that isn't necessarily the right
action; in particular, it makes GENERATED act differently from other
identifiers. Remember that the whole point here is to keep GENERATED
a non-reserved word. Supposing that someone had a column named
GENERATED, your patch would make these queries parse differently:

select x ! generated from ...

select x ! y from ...

So I think attaching a precedence to the GENERATED keyword is dangerous.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2007-04-21 23:43:34 Re: Improving deadlock error messages
Previous Message Neil Conway 2007-04-21 21:56:49 Re: Improving deadlock error messages

Browse pgsql-patches by date

  From Date Subject
Next Message Nikolay Samokhvalov 2007-04-22 07:21:55 Re: xpath_array with namespaces support
Previous Message Tom Lane 2007-04-21 21:01:46 pgsql: Some further performance tweaks for planning large inheritance