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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
