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