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 co
Josh Berkus <[EMAIL PROTECTED]> 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
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
David Fetter <[EMAIL PROTECTED]> 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".
On Fri, Aug 13, 2004 at 07:12:14PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> 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
>
Peter Eisentraut <[EMAIL PROTECTED]> 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 maintena
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 diff
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
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 PROCED
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> 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 go
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 sy
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 woul
Harald Fuchs wrote:
In article <[EMAIL PROTECTED]>,
Oliver Jowett <[EMAIL PROTECTED]> 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 t
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 mi
In article <[EMAIL PROTECTED]>,
Oliver Jowett <[EMAIL PROTECTED]> 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
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 fo
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: candidate
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 broug
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
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
Robert Treat <[EMAIL PROTECTED]> 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 lik
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 f
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 disal
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 parameter
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, f
"Jim C. Nasby" <[EMAIL PROTECTED]> 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-ind
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
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 b
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 equiv
David Fetter <[EMAIL PROTECTED]> 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
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 TE
31 matches
Mail list logo
