Tom Lane wrote:
Yeah, I don't like putting extra restrictions on the polymorphic case
either. Also, see my nearby note about how letting fewer defaults win
over more defaults might be unsafe. Consider
foo (f1 int)
foo (f1 int, f2 variadic int[])
If the system allows f2 to be
2008/12/17 Peter Eisentraut pete...@gmx.net:
On Wednesday 17 December 2008 02:07:35 Tom Lane wrote:
Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/17 Peter Eisentraut pete...@gmx.net:
That looks like a bug to me. Anything that you can do with 1 to N items
should also work for zero.
no, when we discused about variadic functions we defined, so variadic
parameter should not be empty
On Wed, 2008-12-17 at 19:43 +0200, Peter Eisentraut wrote:
That looks like a bug to me. Anything that you can do with 1 to N items
should also work for zero.
Previous discussion link:
http://archives.postgresql.org/pgsql-patches/2008-07/msg00149.php
You can make either mechanism do what
On Tue, 2008-12-16 at 19:07 -0500, Tom Lane wrote:
regression=# select fv(1);
ERROR: function fv(integer) does not exist
LINE 1: select fv(1);
^
HINT: No function matches the given name and argument types. You might need
to add explicit type casts.
ISTM one could make a
Jeff Davis pg...@j-davis.com writes:
Previous discussion link:
http://archives.postgresql.org/pgsql-patches/2008-07/msg00149.php
You can make either mechanism do what you want by defining the right set
of functions. If a minimum of one argument per variadic parameter is
required, you can
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
and it leaves the door open for someone to use something
besides an empty array as the default. (Who are we to say that such a
thing is never useful? NULL seems like a possibly useful default for
instance.)
Another point against that:
Jeff Davis pg...@j-davis.com writes:
On Tue, 2008-12-16 at 19:07 -0500, Tom Lane wrote:
ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument.
We had a similar discussion before, and you replied here:
Peter Eisentraut pete...@gmx.net writes:
Another point against that: If you wanted something else besides an empty
array as default, you can handle that inside the function body by just
looking at how many arguments were passed. Using the default mechanism
provides no added functionality.
On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for that case.
Maybe we'll just let it be for
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the system install a
default behavior for
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more warts and less flexibility if we try to make the
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
This method
eliminates the discrepancy between anyarray and other types of variadic
parameters, and it leaves the door open for someone to use something
besides an empty array as the default. (Who are we to say that such a
thing is never
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
So if I had these two functions ...
var1(a int, b variadic int[])
var2(a int, b variadic anyarray)
... it would be okay to write var1(8), which resolves as var1(8,
array[]::int[]). But if
On Wednesday 17 December 2008 02:07:35 Tom Lane wrote:
Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird
2008/12/17 Gregory Stark st...@enterprisedb.com:
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 17 December 2008 20:50:22 Tom Lane wrote:
The behavior at zero arguments is
certainly a judgment call, but it seems to me that we'll wind up with
more
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/17 Gregory Stark st...@enterprisedb.com:
My inclination would be to say zero arguments is zero arguments and you get a
zero-length array. We could eliminate the problem with anyelement by saying
the variadic argument can't be the only
Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:
regression=# create function fv (f1 int, f2
Tom Lane t...@sss.pgh.pa.us writes:
A related point is that, because the current code forbids a default
for a variadic, you can't do something like
create function foo (f1 int, f2 int default = 42, f3 variadic int[] =
array[]::int[])
ie there's no way to have defaults on the preceding
Tom Lane wrote:
Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:
From a user perspective, if we
Gregory Stark st...@enterprisedb.com writes:
I'm inclined to think an implicit empty array makes the most sense. If a
function-writer wants to enforce a minimum number of arguments they can check
and throw an error.
The question arises though whether it's useful to have any default other than
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics,
Yep, +1 for this approach. I would
Brendan Jurd dire...@gmail.com writes:
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics,
On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, I just realized that there's another fly in the ointment:
the current variadic code allows variadic anyarray, which is
equivalent to an appropriate number of anyelement arguments. If we
allow defaulting then
Brendan Jurd dire...@gmail.com writes:
So if I had these two functions ...
var1(a int, b variadic int[])
var2(a int, b variadic anyarray)
... it would be okay to write var1(8), which resolves as var1(8,
array[]::int[]). But if I tried to write var2(8) I'd get an error.
Maybe something
25 matches
Mail list logo
