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?

-- 
/Dennis Bjï¿½rklund


Sun, 25 Jan 2004 10:13:03 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
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.

Sun, 25 Jan 2004 01:29:15 -0800
david@fetter.org (David Fetter)
Re: Named arguments in function calls

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


25 Jan 2004 12:38:28 -0500
Greg Stark <gsstark@mit.edu>
Re: Named arguments in function calls
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


Sun, 25 Jan 2004 20:29:06 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
Re: Named arguments in function calls
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

Sun, 25 Jan 2004 14:54:12 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Named arguments in function calls 
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, Jan 25, 2004 at 02:54:12PM -0500, Tom Lane wrote:
> 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Sun, 25 Jan 2004 13:43:25 -0800
elein <elein@varlena.com>
Re: Named arguments in function calls
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


Sun, 25 Jan 2004 22:52:09 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
Re: Named arguments in function calls
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

Sun, 25 Jan 2004 17:23:09 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Named arguments in function calls 
> 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.


Sun, 25 Jan 2004 17:32:31 -0500
Rod Taylor <pg@rbt.ca>
Re: Named arguments in function calls


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


Sun, 25 Jan 2004 18:00:09 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: Named arguments in function calls
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


25 Jan 2004 18:21:46 -0500
Greg Stark <gsstark@mit.edu>
Re: Named arguments in function calls
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


Sun, 25 Jan 2004 18:42:20 -0500
Neil Conway <neilc@samurai.com>
Re: Named arguments in function calls
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

Sun, 25 Jan 2004 19:21:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Named arguments in function calls 
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


Mon, 26 Jan 2004 06:10:59 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
Re: Named arguments in function calls
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.


Mon, 26 Jan 2004 17:03:45 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: Named arguments in function calls
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

Mon, 26 Jan 2004 11:22:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Named arguments in function calls 
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

Mon, 26 Jan 2004 11:24:01 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Named arguments in function calls 
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.

Mon, 26 Jan 2004 18:00:58 +0000 (GMT)
Matthew Kirkwood <matthew@hairy.beasts.org>
Re: Named arguments in function calls 
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

Mon, 26 Jan 2004 14:48:04 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Named arguments in function calls 