Korry Douglas <[email protected]> writes:
> It seems to me that trim_list should defined as:
> trim_list: a_expr FROM a_expr { $$ = list_make2($3, $1); }
> | FROM a_expr { $$ = list_make1($2); }
> | a_expr { $$ =
> list_make1($1); }
> Am I missing something?
That will break the ability to call trim() with ordinary function
syntax.
We possibly could change that in conjunction with adding a straight
TRIM '(' expr_list ')' production, though.
What this looks like to me is somebody was trying to allow for future
extensions in the keyword-ized syntax, but I can't imagine the SQL
committee introducing a mix of keyword-ized and non-keyword-ized
arguments. So I agree that the expr_list cases are pretty silly
except for the bare no-keyword-anywhere path.
Actually, on closer examination I think there's another bug here.
I see this in SQL99:
<trim function> ::=
TRIM <left paren> <trim operands> <right paren>
<trim operands> ::=
[ [ <trim specification> ] [ <trim character> ] FROM ] <trim
source>
<trim specification> ::=
LEADING
| TRAILING
| BOTH
<trim character> ::= <character value expression>
<trim source> ::= <character value expression>
It looks to me like you're not supposed to be able to omit FROM if
you've written a <trim specification>. Should we tighten our
syntax to reject that?
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
