Kind people,

I've brought this up before, and with Dennis BjÅrklund's help, would
like to bring it up again.  Here's the idea:

I'd like to be able to create functions with named parameters that
could be called with the names in any order.  For example,

CREATE OR REPLACE FUNCTION foo_func(name TEXT, val INTEGER) AS ...

SELECT foo_func(val AS 23, name AS 'Name goes here');

and have it Do The Right Thing.

Dennis has pointed out that mixing the call-with-named-parameter
interface with call-by-order-of-parameters one would cause confusion,
and I think it would be OK to disallow this type mixing, so

SELECT foo_func(name AS 'yet another name', 35);

would be disallowed.

A calling convention that names parameters makes it a lot easier to
track just exactly what parameter is set to which value, and lets
people not have to memorize what order those named parameters appear
in.  On a related note, it would also be nice to have default
parameters and some way to say to use them.

Well, that's my thoughts so far.  What are yours?

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

Remember to vote!

Fri, 13 Aug 2004 14:41:48 -0700
David Fetter <david@fetter.org>
Calling PL functions with named parameters
David Fetter wrote:
> Dennis has pointed out that mixing the call-with-named-parameter
> interface with call-by-order-of-parameters one would cause confusion,
> and I think it would be OK to disallow this type mixing, so
> 
> SELECT foo_func(name AS 'yet another name', 35);
> 
> would be disallowed.

Python's equivalent syntax allows you to mix the two forms so long as 
all the by-position parameters come first:

 >>> def f(a,b,c,d):
...   print a,b,c,d
...
 >>> f(1,2,3,4)
1 2 3 4
 >>> f(1,2,c=3,d=4)
1 2 3 4
 >>> f(1,2,d=4,c=3)
1 2 3 4
 >>> f(1,d=4,2,c=3)
SyntaxError: non-keyword arg after keyword arg

-O

Sat, 14 Aug 2004 10:05:16 +1200
Oliver Jowett <oliver@opencloud.com>
Re: Calling PL functions with named parameters
David Fetter <david@fetter.org> writes:
> CREATE OR REPLACE FUNCTION foo_func(name TEXT, val INTEGER) AS ...

> SELECT foo_func(val AS 23, name AS 'Name goes here');

I don't think that syntax will work.  You could possibly do it the other
way round:

SELECT foo_func(23 AS val, 'Name goes here' AS name);

which would have some commonality with SELECT's column-labeling syntax
but otherwise seems to have little to recommend it.  Are there any other
vendors supporting such things in SQL, and if so how do they do it?

A bigger issue is how do you see this interacting with resolution of
ambiguous/overloaded function names.

> On a related note, it would also be nice to have default
> parameters and some way to say to use them.

That is fundamentally not ever going to happen, because it blows
overloaded-function resolution out of the water: there is no way to
choose whether "foo(42, 2.5)" matches foo(int, float) or
foo(int, float, something-with-a-default).  Let's try to limit our
attention to something that might actually work.

			regards, tom lane

Fri, 13 Aug 2004 18:22:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Calling PL functions with named parameters 
I would personally find this useful, but I would suggest using Oracle's
syntax of SELECT func(a=>2, b=>'b', ...);

Having said that, having the concept of DEFAULT for parameters wolud be
even more useful, ie:

CREATE FUNCTION blah (
    a int
    , b int DEFAULT 0
);

SELECT blah(1,0);
and
SELECT blah(1);
would do the same thing. (Yes, I know there's a work-around, but it's a
bit of a pain if you've got 10 parameters that could be omitted).

On Fri, Aug 13, 2004 at 02:41:48PM -0700, David Fetter wrote:
> Kind people,
> 
> I've brought this up before, and with Dennis Bjőrklund's help, would
> like to bring it up again.  Here's the idea:
> 
> I'd like to be able to create functions with named parameters that
> could be called with the names in any order.  For example,
> 
> CREATE OR REPLACE FUNCTION foo_func(name TEXT, val INTEGER) AS ...
> 
> SELECT foo_func(val AS 23, name AS 'Name goes here');
> 
> and have it Do The Right Thing.
> 
> Dennis has pointed out that mixing the call-with-named-parameter
> interface with call-by-order-of-parameters one would cause confusion,
> and I think it would be OK to disallow this type mixing, so
> 
> SELECT foo_func(name AS 'yet another name', 35);
> 
> would be disallowed.
> 
> A calling convention that names parameters makes it a lot easier to
> track just exactly what parameter is set to which value, and lets
> people not have to memorize what order those named parameters appear
> in.  On a related note, it would also be nice to have default
> parameters and some way to say to use them.
> 
> Well, that's my thoughts so far.  What are yours?
> 
> Cheers,
> D
> -- 
> David Fetter david@fetter.org http://fetter.org/
> phone: +1 510 893 6100   mobile: +1 415 235 3778
> 
> Remember to vote!
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Fri, 13 Aug 2004 17:49:07 -0500
"Jim C. Nasby" <decibel@decibel.org>
Re: Calling PL functions with named parameters
On Fri, Aug 13, 2004 at 06:22:25PM -0400, Tom Lane wrote:
> > On a related note, it would also be nice to have default
> > parameters and some way to say to use them.
> 
> That is fundamentally not ever going to happen, because it blows
> overloaded-function resolution out of the water: there is no way to
> choose whether "foo(42, 2.5)" matches foo(int, float) or
> foo(int, float, something-with-a-default).  Let's try to limit our
> attention to something that might actually work.
 
Actually, it is possible because Oracle does it. Presumably they treat a
function with defaults as being the equivalent number of overloaded
functions when functions are created, to ensure it can always resolve
what function to call.

IOW, their function resolution code treats a(int, int default 0) as
being equivalent to a(int) and a(int, int).
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Fri, 13 Aug 2004 17:58:12 -0500
"Jim C. Nasby" <decibel@decibel.org>
Re: Calling PL functions with named parameters
Oliver Jowett wrote:

> David Fetter wrote:
> 
>> Dennis has pointed out that mixing the call-with-named-parameter
>> interface with call-by-order-of-parameters one would cause confusion,
>> and I think it would be OK to disallow this type mixing, so
>>
>> SELECT foo_func(name AS 'yet another name', 35);
>>
>> would be disallowed.
> 
> 
> Python's equivalent syntax allows you to mix the two forms so long as 
> all the by-position parameters come first:
> 
>  >>> def f(a,b,c,d):
> ...   print a,b,c,d
> ...
>  >>> f(1,2,3,4)
> 1 2 3 4
>  >>> f(1,2,c=3,d=4)
> 1 2 3 4
>  >>> f(1,2,d=4,c=3)
> 1 2 3 4
>  >>> f(1,d=4,2,c=3)
> SyntaxError: non-keyword arg after keyword arg

python don't have overloaded function...



Regards
Gaetano Mendola

Sat, 14 Aug 2004 01:10:48 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Calling PL functions with named parameters
"Jim C. Nasby" <decibel@decibel.org> writes:
> IOW, their function resolution code treats a(int, int default 0) as
> being equivalent to a(int) and a(int, int).

So you are willing to prohibit a(int) from existing in parallel with
a(int, int-with-a-default) ?

I'll be interested to see the unique-index scheme for pg_proc to enforce
that ;-)

However this does point up the fact that there already *is* a way to
accomplish the task, which is just to create some helper function(s) to
supply the default(s).  Perhaps we can leave it at that for the time
being, and concentrate on adding real new functionality.

			regards, tom lane

Fri, 13 Aug 2004 19:12:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Calling PL functions with named parameters 
Tom Lane wrote:

>>On a related note, it would also be nice to have default
>>parameters and some way to say to use them.
> 
> 
> That is fundamentally not ever going to happen, because it blows
> overloaded-function resolution out of the water: there is no way to
> choose whether "foo(42, 2.5)" matches foo(int, float) or
> foo(int, float, something-with-a-default).  Let's try to limit our
> attention to something that might actually work.

C++ manages to solve this problem, although I can't remember the exact 
mechanics (and C++ is usually not a good example to follow anyway ;)

How about just disallowing function signatures that cause ambiguity? 
i.e. make f(t1,t2,default t3,default t4,..) lay claim to f(t1,t2), 
f(t1,t2,t3), f(t1,t2,t3,t4) etc, and creation fails if any of those 
signatures are already claimed by another function.

-O

Sat, 14 Aug 2004 11:18:18 +1200
Oliver Jowett <oliver@opencloud.com>
Re: Calling PL functions with named parameters
Gaetano Mendola wrote:
> Oliver Jowett wrote:
> 
>> David Fetter wrote:
>>
>>> Dennis has pointed out that mixing the call-with-named-parameter
>>> interface with call-by-order-of-parameters one would cause confusion,
>>
>> Python's equivalent syntax allows you to mix the two forms so long as 
>> all the by-position parameters come first:
>>
> python don't have overloaded functions...

It doesn't change how you'd handle overloaded functions; you still have 
a type for every parameter available.

-O

Sat, 14 Aug 2004 11:35:15 +1200
Oliver Jowett <oliver@opencloud.com>
Re: Calling PL functions with named parameters
Would it be any better to allow

SELECT blah(1,DEFAULT); 

?

Robert Treat

On Friday 13 August 2004 18:49, Jim C. Nasby wrote:
> I would personally find this useful, but I would suggest using Oracle's
> syntax of SELECT func(a=>2, b=>'b', ...);
>
> Having said that, having the concept of DEFAULT for parameters wolud be
> even more useful, ie:
>
> CREATE FUNCTION blah (
>     a int
>     , b int DEFAULT 0
> );
>
> SELECT blah(1,0);
> and
> SELECT blah(1);
> would do the same thing. (Yes, I know there's a work-around, but it's a
> bit of a pain if you've got 10 parameters that could be omitted).
>
> On Fri, Aug 13, 2004 at 02:41:48PM -0700, David Fetter wrote:
> > Kind people,
> >
> > I've brought this up before, and with Dennis BjÅrklund's help, would
> > like to bring it up again.  Here's the idea:
> >
> > I'd like to be able to create functions with named parameters that
> > could be called with the names in any order.  For example,
> >
> > CREATE OR REPLACE FUNCTION foo_func(name TEXT, val INTEGER) AS ...
> >
> > SELECT foo_func(val AS 23, name AS 'Name goes here');
> >
> > and have it Do The Right Thing.
> >
> > Dennis has pointed out that mixing the call-with-named-parameter
> > interface with call-by-order-of-parameters one would cause confusion,
> > and I think it would be OK to disallow this type mixing, so
> >
> > SELECT foo_func(name AS 'yet another name', 35);
> >
> > would be disallowed.
> >
> > A calling convention that names parameters makes it a lot easier to
> > track just exactly what parameter is set to which value, and lets
> > people not have to memorize what order those named parameters appear
> > in.  On a related note, it would also be nice to have default
> > parameters and some way to say to use them.
> >
> > Well, that's my thoughts so far.  What are yours?
> >
> > Cheers,
> > D
> > --
> > David Fetter david@fetter.org http://fetter.org/
> > phone: +1 510 893 6100   mobile: +1 415 235 3778
> >
> > Remember to vote!
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend

-- 
Robert Treat
Build A Better Lamp :: Linux Apache {middleware} PostgreSQL

Fri, 13 Aug 2004 21:18:10 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: Calling PL functions with named parameters
Robert Treat <xzilla@users.sourceforge.net> writes:
> Would it be any better to allow
> SELECT blah(1,DEFAULT); 

Not a lot.  If there is more than one 2-parameter blah(), how do you
pick?  The DEFAULT gives you no clue at all about the type of the
second parameter...

I think if we wanted to do something like this, the right way would be
that "create function foo(f1 text, f2 int default 42)" implicitly
creates a second function "foo(f1 text)", and we make no change to the
matching rules.  But managing this seems mighty messy --- for instance,
we don't presently have any concept of hidden or second-class-citizen
entries in pg_proc, but we'd have to create one to keep the implicitly
created functions out of your face in pg_dump, psql \df, etc.  And
again, it's not really giving you anything you can't have today.

			regards, tom lane

Fri, 13 Aug 2004 23:12:36 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Calling PL functions with named parameters 
Oliver Jowett wrote:

> Tom Lane wrote:
> 
>>> On a related note, it would also be nice to have default
>>> parameters and some way to say to use them.
>>
>>
>>
>> That is fundamentally not ever going to happen, because it blows
>> overloaded-function resolution out of the water: there is no way to
>> choose whether "foo(42, 2.5)" matches foo(int, float) or
>> foo(int, float, something-with-a-default).  Let's try to limit our
>> attention to something that might actually work.
> 
> 
> C++ manages to solve this problem, although I can't remember the exact 
> mechanics (and C++ is usually not a good example to follow anyway ;)

Your're wrong:

try to compile this:

void foo( int a, float b ) { }
void foo( int a, float b, int c=0 ) { }

int main(char argc, char **argv)
{
  foo( 42, 2.5 );

  return 0;
}

you'll get:

a.cpp:6: error: call of overloaded `foo(int, double)' is ambiguous
a.cpp:1: error: candidates are: void foo(int, float)
a.cpp:2: error:                 void foo(int, float, int)

usualy C++ is not a good example as SQL is not  :-)




Regards
Gaetano Mendola





Sat, 14 Aug 2004 10:16:27 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Calling PL functions with named parameters
Oliver Jowett wrote:

> Gaetano Mendola wrote:
> 
>> Oliver Jowett wrote:
>>
>>> David Fetter wrote:
>>>
>>>> Dennis has pointed out that mixing the call-with-named-parameter
>>>> interface with call-by-order-of-parameters one would cause confusion,
>>>
>>>
>>> Python's equivalent syntax allows you to mix the two forms so long as 
>>> all the by-position parameters come first:
>>>
>> python don't have overloaded functions...
> 
> 
> It doesn't change how you'd handle overloaded functions; you still have 
> a type for every parameter available.

I think will be a mess that will break the "minor surprise" principle,
even the bad C++ stays away from this field ( se explicit constructors,
and automatic cast limited to only one level ).

I know I know the Koenig Lookup is there as a Damocle's sword...




Regards
Gaetano Mendola








Sat, 14 Aug 2004 10:28:11 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Calling PL functions with named parameters
David Fetter wrote:
> I'd like to be able to create functions with named parameters that
> could be called with the names in any order.  For example,
>
> CREATE OR REPLACE FUNCTION foo_func(name TEXT, val INTEGER) AS ...
>
> SELECT foo_func(val AS 23, name AS 'Name goes here');

When that was brought up last time, I think the hard part was what 
syntax to use.  You can't use AS because SQL uses that for something 
different.  => might be OK, but then we'd need to disallow that as 
operator name.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Sat, 14 Aug 2004 13:37:04 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Calling PL functions with named parameters
Gaetano Mendola wrote:

>> C++ manages to solve this problem, although I can't remember the exact 
>> mechanics (and C++ is usually not a good example to follow anyway ;)
> 
> Your're wrong:
> 
> try to compile this: [...]

> a.cpp:6: error: call of overloaded `foo(int, double)' is ambiguous
> a.cpp:1: error: candidates are: void foo(int, float)
> a.cpp:2: error:                 void foo(int, float, int)
> 
> usualy C++ is not a good example as SQL is not  :-)

I think you just made my point for me. C++ allows default parameters and 
resolves the ambiguity by disallowing ambiguous calls when they happen.

I'm not sure why C++ doesn't disallow it at declaration time off the top 
of my head -- perhaps because you'd get inconsistent behaviour if the 
candidates were split across compilation units. Since we don't have that 
problem in the SQL function case, we can disallow ambiguity at the time 
of creating the function.

-O

Sat, 14 Aug 2004 23:47:45 +1200
Oliver Jowett <oliver@opencloud.com>
Re: Calling PL functions with named parameters
Gaetano Mendola wrote:
> Oliver Jowett wrote:
> 
>> Gaetano Mendola wrote:
>>
>>> Oliver Jowett wrote:
>>>
>>>> David Fetter wrote:
>>>>
>>>>> Dennis has pointed out that mixing the call-with-named-parameter
>>>>> interface with call-by-order-of-parameters one would cause confusion,
>>>>
>>>>
>>>>
>>>> Python's equivalent syntax allows you to mix the two forms so long 
>>>> as all the by-position parameters come first:
>>>>
>>> python don't have overloaded functions...
>>
>> It doesn't change how you'd handle overloaded functions; you still 
>> have a type for every parameter available.
> 
> 
> I think will be a mess that will break the "minor surprise" principle,
> even the bad C++ stays away from this field ( se explicit constructors,
> and automatic cast limited to only one level ).

I don't understand your argument. What is the surprising behaviour you 
are worried about?

-O

Sat, 14 Aug 2004 23:52:42 +1200
Oliver Jowett <oliver@opencloud.com>
Re: Calling PL functions with named parameters
In article <411DFBE1.7060007@opencloud.com>,
Oliver Jowett <oliver@opencloud.com> writes:

> I think you just made my point for me. C++ allows default parameters
> and resolves the ambiguity by disallowing ambiguous calls when they
> happen.


> I'm not sure why C++ doesn't disallow it at declaration time off the
> top of my head -- perhaps because you'd get inconsistent behaviour if
> the candidates were split across compilation units.

IIRC this was due to multiple unheritance.  You could inherit methods
with the same name and parameter list from two different base classes.
Disallowing that at declaration time would mean disallowing
inheritance (even indirectly) from these two base classes, even though
the derived class didn't use the ambiguous methods.


14 Aug 2004 15:21:22 +0200
Harald Fuchs <hf0722x@protecting.net>
Re: Calling PL functions with named parameters
Oliver Jowett wrote:

 > Gaetano Mendola wrote:
 >
 >> Oliver Jowett wrote:
 >>
 >>> Gaetano Mendola wrote:
 >>>
 >>>> Oliver Jowett wrote:
 >>>>
 >>>>> David Fetter wrote:
 >>>>>
 >>>>>> Dennis has pointed out that mixing the call-with-named-parameter
 >>>>>> interface with call-by-order-of-parameters one would cause confusion,
 >>>>>
 >>>>>
 >>>>>
 >>>>>
 >>>>> Python's equivalent syntax allows you to mix the two forms so long
 >>>>> as all the by-position parameters come first:
 >>>>>
 >>>> python don't have overloaded functions...
 >>>
 >>>
 >>> It doesn't change how you'd handle overloaded functions; you still
 >>> have a type for every parameter available.
 >>
 >>
 >>
 >> I think will be a mess that will break the "minor surprise" principle,
 >> even the bad C++ stays away from this field ( se explicit constructors,
 >> and automatic cast limited to only one level ).
 >
 >
 > I don't understand your argument. What is the surprising behaviour you
 > are worried about?

I'm worried about:

(1) foo( integer, float);
(2) foo( integer, integer, float a = 3 );

which one is called with:   foo( 2, 2 )?

the first one because have two parameters or the second one
that better match the arguments ?

Whatever policy we adopt someone could argue that the (2) have
a signature with 3 parameters so the (1) shall be called, and
someone can argue that (2) is equivalent to:

(2a) foo(integer, integer)
(2b) foo(integer, integer, float);

so the (2) have to be called.


BTW C++ adopt the latter.



Regards
Gaetano Mendola















Sat, 14 Aug 2004 15:49:12 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Calling PL functions with named parameters
Gaetano Mendola wrote:

>  >>>> Oliver Jowett wrote:
>  >>>>
>  >>>>> David Fetter wrote:
>  >>>>>
>  >>>>>> Dennis has pointed out that mixing the call-with-named-parameter
>  >>>>>> interface with call-by-order-of-parameters one would cause 
> confusion,
>  >>>>>
>  >>>>> Python's equivalent syntax allows you to mix the two forms so long
>  >>>>> as all the by-position parameters come first:

> I'm worried about:
> 
> (1) foo( integer, float);
> (2) foo( integer, integer, float a = 3 );
> 
> which one is called with:   foo( 2, 2 )?

This is a separate issue to the one I was discussing above. I am not 
talking about default arguments at all here; I am talking about mixing 
positional parameter syntax with named parameter syntax.

-O

Sun, 15 Aug 2004 01:58:12 +1200
Oliver Jowett <oliver@opencloud.com>
Re: Calling PL functions with named parameters
Harald Fuchs wrote:

> In article <411DFBE1.7060007@opencloud.com>,
> Oliver Jowett <oliver@opencloud.com> writes:
> 
> 
>>I think you just made my point for me. C++ allows default parameters
>>and resolves the ambiguity by disallowing ambiguous calls when they
>>happen.
> 
> 
> 
>>I'm not sure why C++ doesn't disallow it at declaration time off the
>>top of my head -- perhaps because you'd get inconsistent behaviour if
>>the candidates were split across compilation units.
> 
> 
> IIRC this was due to multiple unheritance.  You could inherit methods
> with the same name and parameter list from two different base classes.
> Disallowing that at declaration time would mean disallowing
> inheritance (even indirectly) from these two base classes, even though
> the derived class didn't use the ambiguous methods.

You get the point, and with a linear hierarchy the last function hide
the previous one:


struct A { void foo(int) {  } };

struct B : A { void foo(int, int a = 3) {  } };


B b;
b.foo(3);

will call the B::foo.




Regards
Gaetano Mendola


Sat, 14 Aug 2004 16:00:32 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Calling PL functions with named parameters
Oliver Jowett wrote:

> Gaetano Mendola wrote:
> 
>>  >>>> Oliver Jowett wrote:
>>  >>>>
>>  >>>>> David Fetter wrote:
>>  >>>>>
>>  >>>>>> Dennis has pointed out that mixing the call-with-named-parameter
>>  >>>>>> interface with call-by-order-of-parameters one would cause 
>> confusion,
>>  >>>>>
>>  >>>>> Python's equivalent syntax allows you to mix the two forms so long
>>  >>>>> as all the by-position parameters come first:
> 
> 
>> I'm worried about:
>>
>> (1) foo( integer, float);
>> (2) foo( integer, integer, float a = 3 );
>>
>> which one is called with:   foo( 2, 2 )?
> 
> 
> This is a separate issue to the one I was discussing above. I am not 
> talking about default arguments at all here; I am talking about mixing 
> positional parameter syntax with named parameter syntax.

I see.


Regards
Gaetano Mendola



Sat, 14 Aug 2004 16:36:20 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Calling PL functions with named parameters
Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> 
>>CREATE OR REPLACE FUNCTION foo_func(name TEXT, val INTEGER) AS ...
> 
> 
>>SELECT foo_func(val AS 23, name AS 'Name goes here');
> 
> 
> I don't think that syntax will work.  You could possibly do it the other
> way round:
> 
> SELECT foo_func(23 AS val, 'Name goes here' AS name);
> 
> which would have some commonality with SELECT's column-labeling syntax
> but otherwise seems to have little to recommend it.  Are there any other
> vendors supporting such things in SQL, and if so how do they do it?

MSSQL's syntax for calling named parameters is like this:

CREATE PROCEDURE SampleProcedure @EmployeeIDParam INT,
	@MaxQuantity INT OUTPUT AS ...

DECLARE @MaxQtyVariable INT
EXEC @rc = SampleProcedure @EmployeeIDParam = 9,
	@MaxQuantity = @MaxQtyVariable OUTPUT

This is commonly used if a parameter should be left default (and I don't 
like it).

Regards,
Andreas

Sat, 14 Aug 2004 17:37:18 +0000
Andreas Pflug <pgadmin@pse-consulting.de>
Re: Calling PL functions with named parameters
On Fri, Aug 13, 2004 at 07:12:14PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > IOW, their function resolution code treats a(int, int default 0)
> > as being equivalent to a(int) and a(int, int).
> 
> So you are willing to prohibit a(int) from existing in parallel with
> a(int, int-with-a-default) ?
> 
> I'll be interested to see the unique-index scheme for pg_proc to
> enforce that ;-)
> 
> However this does point up the fact that there already *is* a way to
> accomplish the task, which is just to create some helper function(s)
> to supply the default(s).  Perhaps we can leave it at that for the
> time being, and concentrate on adding real new functionality.

That'd be neat.  :)

Here's another possibility.  PostgreSQL has already "gone there" with
multidimensional ARRAYs, and thanks, Joe!  What about making HASHes a
first-class object?  This would do two controversial things (that I've
thought of).

1.  Use the => operator, removing it from the pool of unused
operators.

2.  Possibly encourage people to Do The Wrong Thing(TM).

What we'd get for the effort, though, is tighter integration with
languages that have some kind of associative array structure, which is
to say all the "scripting" languages, and an ability to deal with 
data structures to and from queries that more closely matches what the
middleware/front end needs to do.

How big a can of worms am I opening here?

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

Remember to vote!

Mon, 16 Aug 2004 09:01:03 -0700
David Fetter <david@fetter.org>
HASHes [was Re: Calling PL functions with named parameters]
David Fetter <david@fetter.org> writes:
> What about making HASHes a first-class object?

I see less than zero value in this.  You'd have to serialize the
contents to ship it to the client anyway, so there is no particular
point in inventing a random new representation for "row".

			regards, tom lane

Mon, 16 Aug 2004 12:07:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: HASHes [was Re: Calling PL functions with named parameters] 