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

Re: [HACKERS] parser dilemma

From: Zoltan Boszormenyi <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 08:49:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane írta:
> Zoltan Boszormenyi <zb(at)cybertec(dot)at> writes:
>> Andrew Dunstan írta:
>>> Zoltan Boszormenyi wrote:
>>>> On the other hand, marking GENERATED as %right
>>>> solves this issue. I hope it's an acceptable solution.
>>> If anything I should have thought it would be marked %nonassoc.
>> That works, too.
> [ 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.  If you don't have a
> 100% clear understanding of what the ambiguity is and why this is the
> right way to resolve it, you are probably creating a bigger problem.
> 			regards, tom lane

As far as I remember from my math classes, associativity is
the rules about the way brackets are allowed to be used.
Say, multiplication is two-way associative, i.e.:

a * b * c == (a * b) * c == a * (b * c)

If it was only left associative, the line below would be true:

a * b * c == (a * b) * c != a * (b * c)

Similarly, if it was only right-associative, this would be true:

a * b * c == a * (b * c) != (a * b) * c

Precedence is about the implicit bracketing above
two operators, i.e.

a * b + c * d == (a * b) + (c * d)

(Sorry for the poor explanation, my math classes weren't in English.)

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 ...

So, do any of these cause any problems?

Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH

In response to


pgsql-hackers by date

Next:From: Ottó HavasvölgyiDate: 2007-04-21 08:55:07
Subject: Re: Eliminating unnecessary left joins
Previous:From: Tom LaneDate: 2007-04-21 08:06:39
Subject: Re: [HACKERS] parser dilemma

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-21 21:01:46
Subject: pgsql: Some further performance tweaks for planning large inheritance
Previous:From: Tom LaneDate: 2007-04-21 08:06:39
Subject: Re: [HACKERS] parser dilemma

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