Re: Why does TRIM() expect an expr_list?

Korry Douglas <korry(dot)douglas(at)enterprisedb(dot)com> 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