Thread: Calling PL functions with named parameters
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!
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
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
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?"
"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
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
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.
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:>>>>> Gaetano Mendola wrote:>>>>>>> Oliver Jowett wrote:>>>>>>>>> David Fetterwrote:>>>>>>>>>>> Dennis has pointed out that mixing the call-with-named-parameter>>>>>> interface with call-by-order-of-parametersone would cause confusion,>>>>>>>>>>>>>>>>>>>>>>>>> Python's equivalent syntax allows you to mixthe 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 parameteravailable.>>>>>>>> I think will be a mess that will break the "minor surprise" principle,>> even the bad C++ staysaway from this field ( se explicit constructors,>> and automatic cast limited to only one level ).>>> I don't understandyour 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
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