Re: Why does TRIM() expect an expr_list?

Korry Douglas <korry.douglas@enterprisedb.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