2008/7/13 Jeff Davis <[EMAIL PROTECTED]>: > 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 > -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches