Zoltan Boszormenyi <zb@cybertec.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