Tom Lane írta:
Andrew Dunstan [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
Thanks. This idea solved one of the two shift/reduce conflicts.
But the other one can only be solved if I put GENERATED
into the reserved_keyword set. But the standard spec says
it's unreserved. Now what
Zoltan Boszormenyi írta:
Tom Lane írta:
Andrew Dunstan [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
Thanks. This idea solved one of the two shift/reduce conflicts.
But the other one can only be solved if I put GENERATED
into the reserved_keyword set. But the standard spec says
Andrew Dunstan wrote:
Tom Lane wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have to tell if the default expression is 5!
or 5!GENERATED
There are
Alvaro Herrera [EMAIL PROTECTED] writes:
BTW I just noticed this bug in the comment above a_expr:
* Note that '(' a_expr ')' is a b_expr, so an unrestricted expression can
* always be used by surrounding it with parens.
It is wrong because it's not a b_expr, but a c_expr.
Well, it's right
Tom Lane wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have to tell if the default expression is 5!
or 5!GENERATED
There are basically two ways to fix this:
1.
Zoltan Boszormenyi írta:
Andrew Dunstan írta:
Florian G. Pflug wrote:
bison -y -d gram.y
conflicts: 2 shift/reduce
I'ts been quite a time since I last used bison, but as far as I
remember, you can tell it to write a rather details log about
it's analysis of the grammar. That log should
