Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group