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 incl
Zoltan Boszormenyi wrote:
You can almost always get rid of shift/reduce conflicts by unwinding
some of the productions - resist the temptation to factor the
grammar. The effect of this is to eliminate places where the parser
has to decide between shifting and reducing. (This is why, for
exam
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 should I do
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
i
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 ...".
> >
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
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: