Thread: Named arguments in function calls
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
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
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.
On second thought though, it doesn't work.
select func(x is null);
is ambiguous, especially if func() accepts boolean.
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.
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
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
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)