2008/7/13 Jeff Davis <pgsql@j-davis.com>:
> On Tue, 2008-06-24 at 17:10 +0200, Pavel Stehule wrote:
>> Hello
>>
>> this version implements syntax based on argmodes.
>>
>>
>> CREATE FUNCTION mleast(variadic numeric[]) RETURNS numeric AS $$
>> SELECT min($1[i])
>> FROM generate_subscripts($1,1) g(i);
>> $$ LANGUAGE SQL;
>>
>
> I don't have a strong opinion about whether the variadic argument is
> declared as an array or scalar, so I am posting my comments about this
> version of the patch as well.
ok
>
> This version also has a problem when declaring two functions "foo(int)"
> and "foo(variadic int[])". In this version, the declaration is allowed
> but the backend crashes when the function is called.
>
ok, I understand now
> The variable "transform_variadic" should have some kind of comment. It
> seems to be there to distinguish between when you're looking for a
> candidate function for a function call, and when you're looking for a
> candidate function for, e.g., CREATE FUNCTION. It's a little hard to
> follow, and is probably the cause for the aformentioned crash.
>
> Also, it doesn't seem to allow calls to a variadic function with zero
> arguments, e.g. "mleast()". I think this should be allowed.
>
It's not possible for all cases, because empty array have be typed
array still. But for non polymorphic variadic functions it's probably
possible - I would to solve this question later - and for now use
overloading etc
create function mleast() returns ..
create function mleast(variadic params anyarray) returns ...
> I suggest the following error message rewording:
> "variadic argument isn't an array" should be something like: "variadic
> argument must be an array".
>
I invite all you language suggestions. It's really important for me.
> Regards,
> Jeff Davis
>
my thanks
Pavel Stehule
>
