# Re: [PATCHES] [HACKERS] parser dilemma

```Tom Lane írta:
```
```Zoltan Boszormenyi <[EMAIL PROTECTED]> 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
http://www.postgresql.at/