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 d
"Pavel Stehule" writes:
> 2008/12/17 Gregory Stark :
>> 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 polymorphic argument.
> I disagree. Polym
2008/12/17 Gregory Stark :
> Tom Lane writes:
>
>> Peter Eisentraut 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 t
Tom Lane writes:
> Peter Eisentraut 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
>>> def
Peter Eisentraut 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 that cas
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 f
Peter Eisentraut 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.
Well, the
Jeff Davis 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:
> http://archives.postgresql.org/pgsql-patche
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 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 work around it b
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
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
"Pavel Stehule" writes:
> 2008/12/17 Peter Eisentraut :
>> 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 Please, look to archive.
Yeah,
2008/12/17 Peter Eisentraut :
> 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
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 n
On Wednesday 17 December 2008 06:03:06 Tom Lane wrote:
> "Brendan Jurd" 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
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 weir
"Brendan Jurd" 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 like "cannot
On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane 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 there's a big probl
"Brendan Jurd" writes:
> On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane 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 approac
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane 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 intuitively expect
Gregory Stark 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
> an empty array.
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 j
Tom Lane 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 parameters eith
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 variadi
25 matches
Mail list logo
