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

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

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?"

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?"

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

"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

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

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

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

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

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

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

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/

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

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

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.

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

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

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

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

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

David,

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

As we've discussed on IRC, this should be the difference between a FUNCTION
and a PROCEDURE. It's about time we implemented a CREATE PROCEDURE statement
anyway.

As I see it, the critical difference between FUNCTIONS and PROCEDURES can be
that:
a) Procedures support named parameter calling but do NOT allow being called in
the context of a query, and
b) Procedures are not automatically transactional; that is, transactions
within procedures must/can be explicit. Among other things, this would allow
procedures to run maintainence tasks.

This seems to me to be the obvious solution to the Named Parameters vs.
Overloading conflict, and I'm really puzzled why people keep dismissing it as
out-of-hand.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus 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

As we've discussed on IRC, this should be the difference between a
FUNCTION and a PROCEDURE.

Huh? As far as I can tell, the difference between a function and a
procedure is precisely that the latter doesn't return a value. A
consistent way to specify the parameters of either one would certainly
be highly desirable.

b) Procedures are not automatically transactional; that is,
transactions within procedures must/can be explicit. Among other
things, this would allow procedures to run maintainence tasks.

I certainly want all my maintenance tasks to be transactional. Being
nontransactional is a fuzzy idea anyway. You can't really run anything
without a transaction in PostgreSQL.

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

Peter Eisentraut wrote:

Josh Berkus 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

As we've discussed on IRC, this should be the difference between a
FUNCTION and a PROCEDURE.

Huh? As far as I can tell, the difference between a function and a
procedure is precisely that the latter doesn't return a value. A
consistent way to specify the parameters of either one would certainly
be highly desirable.

b) Procedures are not automatically transactional; that is,
transactions within procedures must/can be explicit. Among other
things, this would allow procedures to run maintainence tasks.

I certainly want all my maintenance tasks to be transactional. Being
nontransactional is a fuzzy idea anyway. You can't really run anything
without a transaction in PostgreSQL.

I think you're right on both counts.

ISTM we need a more strategic discussion of where we want to go with
procedural code.

some other ideas to consider:
- it would be nice to be able to say PERFORM 'string with plcode'
language plname;
- OUT / INOUT parameters

I think we need an idea of where we are going with all this stuff,
rather than approaching the area piecemeal in a way that might preclude
other decisions we might want to make later.

cheers

andrew

Peter Eisentraut <peter_e@gmx.net> writes:

Josh Berkus wrote:

b) Procedures are not automatically transactional; that is,
transactions within procedures must/can be explicit. Among other
things, this would allow procedures to run maintainence tasks.

I certainly want all my maintenance tasks to be transactional. Being
nontransactional is a fuzzy idea anyway. You can't really run anything
without a transaction in PostgreSQL.

Yeah, but the point is that a procedure in these terms could start and
end transactions. Right now, any process you want to perform that has
to span more than one transaction has to be driven by client-side code.
It *would* be nice to be able to encapsulate such things totally on the
server side. The actual work would of course all be inside
transactions, but if we could have (some limited amount of) control
logic outside it would be a nice addition.

I agree however with Andrew's nearby point that this is completely
unrelated to named parameters to functions/procedures, or to defaults
for parameters.

regards, tom lane

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!

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

Tom,

I agree however with Andrew's nearby point that this is completely
unrelated to named parameters to functions/procedures, or to defaults
for parameters.

I think that was Peter's point, not Andrew's. Andrew agreed with me.

I do think, though, that we should hammer out the parameters, functions,
procedures, etc. "master plan" before anyone gets further coding them, if
people are up for it.

Tom, just to be perfectly clear about why I see Procedures as a way of
resolving parameter ambiguity, my idea is that:
FUNCTIONS will support overloading but will not support named parameter
calling;
PROCEDURES will support named parameter calling but not support overloading.

This resolves the ambiguity. Particularly, I'm concerned about adding any
more code to the evaluation of a function call, out of fear that it will have
a significant performance impact due to increased time to evaluate built-in
functions.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

Tom, just to be perfectly clear about why I see Procedures as a way of
resolving parameter ambiguity, my idea is that:
FUNCTIONS will support overloading but will not support named parameter
calling;
PROCEDURES will support named parameter calling but not support overloading.

Understood, but this seems like a bad design to me, because it's
non-orthogonal.

Particularly, I'm concerned about adding any more code to the
evaluation of a function call, out of fear that it will have a
significant performance impact due to increased time to evaluate
built-in functions.

I think that named params would have no significant extra cost *when not
used*, so I'm not sure the above concern is a big deal. (I do worry
about the cost implications of defaultable parameters, however, as that
seems likely to expand the search space for a matching function quite a
bit.)

regards, tom lane

Tom,

Understood, but this seems like a bad design to me, because it's
non-orthogonal.

Or just a natural consequence of our having loaded Functions down with all of
the functionality usually assigned to Procedures over the years.

I think that named params would have no significant extra cost *when not
used*, so I'm not sure the above concern is a big deal. (I do worry
about the cost implications of defaultable parameters, however, as that
seems likely to expand the search space for a matching function quite a
bit.)

Well, since default params is one of the critical reasons to use named param
calling in the first place, I think this is a significant concern.

I'm also not looking forward to all of the "help" e-mails we'll get to
PGSQL-SQL in response to: "Your function cannot be created as specified due
to a namespace conflict." ... particularly if this happens during database
reload as a result of new functions in Template1.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco