Re: variadic function support
От | Pavel Stehule |
---|---|
Тема | Re: variadic function support |
Дата | |
Msg-id | 162867790806240810jc61fd56le8563fe4f7d9a265@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: variadic function support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: variadic function support
|
Список | pgsql-patches |
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; Regards Pavel Stehule 2008/6/24 Tom Lane <tgl@sss.pgh.pa.us>: > Andrew Dunstan <andrew@dunslane.net> writes: >> But if I have >> foo( a text, b int[]) >> it looks odd if both these calls are legal: >> foo('a',1,2,3,) >> foo('a',ARRAY[1,2,3]) >> which I understand would be the case with the current patch. > > Maybe I misunderstand what is supposed to happen, but I believe that > if the function is marked VARIADIC then the second case would in fact > be rejected: the signature of the function for parameter-matching > purposes is text followed by one or more ints, never text and int[]. > >> I'm also still curious to know how the following would be handled: >> foo(a text[], b text[]) > > I think a is just text[], full stop. Only the last parameter is > interpreted differently for variadic. > > Your point about the syntax is good though. It would be better if > the syntax were like > > create function foo (a text, variadic b int[]) > > or maybe even better > > create function foo (a text, variadic b int) > > since (a) this makes it much more obvious to the reader what the > function might match, and (b) it leaves the door open for marking > multiple parameters as variadic, if we can figure out what that means. > > regards, tom lane >
Вложения
В списке pgsql-patches по дате отправления: