Named arguments in function calls

In article <Pine.LNX.4.44.0401251005300.30205-100000@zigo.dhs.org> you wrote:

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.

It's specified as => in the todo, and it's the symbol used by oracle
in their pl/sql so I hope it's okay that I steal that symbol?

You can't be stealing it if it's in the TODO :)

Oh, and Peter E, please consider putting a sock in the "No!" you
almost always pipe up with. It's getting boring.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 cell: +1 415 235 3778

America is like a melting pot: The people on the bottom get burned
and the scum floats to the top.

david@fetter.org (David Fetter) writes:

In article <Pine.LNX.4.44.0401251005300.30205-100000@zigo.dhs.org> you wrote:

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.

--
greg

On 25 Jan 2004, Greg Stark wrote:

foo (x => 13, y => 42)

Is it really necessary to steal it?

Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious and there is no
clean way to fix that. Say that => is an operator returning a boolean,
then the above could either be the function foo called with x=13 and y=42
or the function foo called with two booleans.

We could of course make up some other syntax that does not involve => but
then you loose compability with oracle.

I've not checked if there is anything similar in the sql2003 draft yet.
I will do that of course. If someone has information about that, please
speak up.

--
/Dennis Bj�rklund

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

I agree with Tom on this. Good operator combinations
are hard to find when you are creating new operators.
=> is a particularly good one.

Barring any override from the SQL200x standard,
I would strongly suggest AS, too.

elein
elein@varlena.com

On Sun, 25 Jan 2004, elein wrote:

Barring any override from the SQL200x standard,
I would strongly suggest AS, too.

I kind of like AS also now after thinking about it. The only reason for =>
is that oracle used it, nothing else.

As I wrote in another mail, I will check out sql200x.

foo (13 as x, 42 as y)

The only question now is if it should be that we call the function with
the variable x AS the value 13, or if we call the function with 13 AS the
variable x. I.e.

foo (13 as x)

or

foo (x as 13)

I don't know if one is more natural then the other in english. To my
swedish ear both sounds as good. I like (x as 13) a little better, but I
don't really care much what way around it will be.

--
/Dennis Bj�rklund

Dennis Bjorklund <db@zigo.dhs.org> writes:

I kind of like AS also now after thinking about it. The only reason for =>
is that oracle used it, nothing else.

Peter Eisentraut pointed out to me that I'd missed a conflicting feature
in SQL99: that spec uses "value AS type" in some function-call contexts.
It's essentially a cast without the CAST() decoration. (See
<SQL argument list> and <generalized expression>.)

I'm not sure if we'll ever get around to implementing SQL99's ideas
about user-defined types; they seem pretty bizarre. But it is probably
unwise to select a directly conflicting syntax for parameter names.

So, back to the drawing board ... what else can we use?

regards, tom lane

The only question now is if it should be that we call the function with
the variable x AS the value 13, or if we call the function with 13 AS the
variable x. I.e.

...

I don't know if one is more natural then the other in english. To my
swedish ear both sounds as good. I like (x as 13) a little better, but I
don't really care much what way around it will be.

If that was IS, then foo(x is 13) makes sense. I prefer foo(13 as x),
as in call foo with value 13 known as x.

Tom Lane wrote:

Dennis Bjorklund <db@zigo.dhs.org> writes:

I kind of like AS also now after thinking about it. The only reason for =>
is that oracle used it, nothing else.

Peter Eisentraut pointed out to me that I'd missed a conflicting feature
in SQL99: that spec uses "value AS type" in some function-call contexts.
It's essentially a cast without the CAST() decoration. (See
<SQL argument list> and <generalized expression>.)

I'm not sure if we'll ever get around to implementing SQL99's ideas
about user-defined types; they seem pretty bizarre. But it is probably
unwise to select a directly conflicting syntax for parameter names.

So, back to the drawing board ... what else can we use?

I actually rather like the Oracle syntax. As an old Ada programmer
(there are damn few of us left) I feel right at home with it ;-). Perl
programmers should feel quite comfortable with it too (just think of the
arguments as a hash).

OTOH I understand the objections, but they don't strike me as
necessarily conclusive.

cheers

andrew

Dennis Bjorklund <db@zigo.dhs.org> writes:

On 25 Jan 2004, Greg Stark wrote:

foo (x => 13, y => 42)

Is it really necessary to steal it?

Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious and there is no
clean way to fix that.

Of course it's ambiguous. Just as f(a,b) is ambiguous in C. It could mean call
f with two arguments, or it could mean call f with the result of the
expression "a,b". It's "fixed" by just declaring "," special inside function
calls. If you want to use the operator in the function call you have to use an
extra set of parentheses.

I'm sure that's a bit harder when you want => to be a regular identifier
outside of a function call. And the dual meaning of => is a pretty big wart,
But the compatibility with Oracle would be awfully nice. Named parameters are
going to be pretty ubiquitous once they're supported.

--
greg

Greg Stark <gsstark@mit.edu> writes:

But the compatibility with Oracle would be awfully nice.

Perhaps I'm missing something here: why is compatibility with Oracle
here particularly worth worrying about? Supporting the same
functionality as Oracle is good, but ISTM supporting the exact same
syntax is far less important. Anyone porting non-trivial PL/SQL to
PostgreSQL will have bigger fish to fry than doing s/=>/AS/ or
what have you.

-Neil

Greg Stark <gsstark@mit.edu> writes:

Of course it's ambiguous. Just as f(a,b) is ambiguous in C. It could
mean call f with two arguments, or it could mean call f with the
result of the expression "a,b". It's "fixed" by just declaring ","
special inside function calls. If you want to use the operator in the
function call you have to use an extra set of parentheses.

This doesn't apply very well to Postgres, though. For us ',' is not a
legal operator name anywhere. We used to have some conflicts between
punctuation and operator names --- at one point, there were actually
standard operators named ';' and ':' if you can believe that. We got
rid of those cases because of the amount of pain they caused, and I'm
not eager to introduce a new one.

regards, tom lane

On 25 Jan 2004, Greg Stark wrote:

expression "a,b". It's "fixed" by just declaring "," special inside function
calls. If you want to use the operator in the function call you have to use an
extra set of parentheses.

Well, it would work. It's just that it felt like such a big hack that I
didn't want to touch it at first. In general if one adds one thing like
this after another, we end up like some other database with lots of
strange ugly features.

I'm sure that's a bit harder when you want => to be a regular identifier
outside of a function call.

It doesn't have to be very hard to parse it. One can just parse it as an
expression and have a transformation phase that checks if the expression
is a top level "=>" with a single identifier to the left. If it is we
transform it to named argument. Probably one also need to record if the
top level expression is in () and set a flag to not trigger the above
logic.

--
/Dennis Bj�rklund

Rod Taylor wrote:

If that was IS, then foo(x is 13) makes sense.

I like that syntax. For example

select interest(amount is 500.00, rate is 1.3)

is very readable, yet brief.

Peter Eisentraut <peter_e@gmx.net> writes:

Rod Taylor wrote:

If that was IS, then foo(x is 13) makes sense.

I like that syntax. For example

select interest(amount is 500.00, rate is 1.3)

is very readable, yet brief.

Yes, that does read well. And "IS" is already a keyword. We might have
to promote it from func_name_keyword to fully reserved status, but that
doesn't seem like a big loss. I could go with this.

(We still need to check SQL200x though ...)

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Rod Taylor wrote:

If that was IS, then foo(x is 13) makes sense.

I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.

On second thought though, it doesn't work.

select func(x is null);

is ambiguous, especially if func() accepts boolean.

regards, tom lane

On Mon, 26 Jan 2004, Tom Lane wrote:

If that was IS, then foo(x is 13) makes sense.

I like that syntax. For example
select interest(amount is 500.00, rate is 1.3)
is very readable, yet brief.

On second thought though, it doesn't work.

select func(x is null);

is ambiguous, especially if func() accepts boolean.

You're unlikely to care, but Oracle's syntax is Perlish:

select interest(amount => 500.0, rate => 1.3);

That'd be ambiguous again, though. Perhaps:

select interest(amount := 500.0, rate := 1.3);

?

Matthew.

Matthew Kirkwood <matthew@hairy.beasts.org> writes:

... Perhaps:

select interest(amount := 500.0, rate := 1.3);

That might work, since := isn't a legal operator name. It might pose a
conflict for clients like ECPG that like to use ":name" as a parameter
indicator, but since we don't have an identifier directly following ":"
it seems like they could cope.

regards, tom lane