Greg Stark <gsstark@mit.edu> writes:
>> I've been looking (and coded) a little bit on named function calls.
>> Calls on the form:
>>
>> foo (x => 13, y => 42)
>>
>> Implementing this means that the symbol => no longer can be defined
>> by the user as an operator. It's not used as default in pg, but I
>> just want to tell you up front in case you don't like that.
> Is it really necessary to steal it? There's some precedent for special cases
> in argument lists: "," is an operator in C yet it has special meaning in
> function arguments.
I'm not happy with the concept of "reserved operator names", either.
I think a little more work ought to be put into the grammar to see if
we can match Oracle's syntax without reserving the operator, and if we
can't, choose a different syntax using a keyword instead of an operator.
One that comes to mind immediately is AS:
foo (13 as x, 42 as y)
AS is already a fully reserved word, so this wouldn't break any existing
applications. Furthermore it seems to fit more naturally with SQL
syntax in general --- you could see this as equivalent to the column
renaming that AS does in a SELECT list.
I've never been impressed with the concept of copying Oracle just
because they're Oracle. This seems like a case where they've chosen
an unfortunate syntax that we should not break things to emulate.
BTW, has anyone looked to see whether SQL 200x has pre-empted this
decision yet?
regards, tom lane