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
a(int,
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.
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,
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 but
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
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,
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
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
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:
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
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
top of
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
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 time
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
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
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
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
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
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
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 maintenance tasks
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
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
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
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
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
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-index
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,
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
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
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
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 like
31 matches
Mail list logo
