Re: Why does TRIM() expect an expr_list?

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