Tom Lane írta:
> Zoltan Boszormenyi <zb@cybertec.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
http://www.postgresql.at/
