Re: Why does TRIM() expect an expr_list? - Mailing list pgsql-hackers

>> 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.

Hmm... it seems counterintuitive to call TRIM() using ordinary  
function syntax anyway.  What would the argument list look like?

I think you would have to reverse the order of the arguments (and  
there's no way to factor the LEADING/TRAILING/BOTH stuff into the  
argument list since those map to calls to different functions).
 For example to write:
TRIM( 'foo' FROM 'foobar' )

using function syntax, you would have to write:
TRIM( 'foobar', 'foo' )

As far as I know, that usage is not documented anywhere.  And since  
"trim" is not really a function, you can't discover the proper  
argument list using \df

On the other hand, someone is surely (ab)using TRIM() that way...
> 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.

I suspect that it was simply easier to write it that way than to code  
the make_list1() invocations, but who knows.

> 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?


That depends on how much code you want to break.  Doesn't really  
matter to me.
-- Korry

-----------------------------------------------------------------------
Korry Douglas
Senior Database Dude
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: (804)241-4301
Mobile: (620) EDB-NERD