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 basically two ways to fix this:
> >
> >1. Collapse GENERATED ALWAYS and GENERATED BY into single tokens
> >using filtered_base_yylex.
> >
> >2. Stop allowing postfix operators in b_expr.
>
> I can't think of any good reason why we need postfix operators at all.
> Plenty of languages do quite happily without them, and where they make
> some sense (e.g. in C) they do so because of their side effect, which
> doesn't seem relevant here.
>
> So I vote for #2 unless it will break too much legacy stuff. You should
> always be able to replace "operand postop" with a function call anyway -
> it's arguably just syntactic sugar.
Is it not enough to enclose the expression in parentheses? ISTM that
this rule covers this:
c_expr:
| '(' a_expr ')' opt_indirection
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.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
