Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch

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