From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: variadic function support |
Date: | 2008-06-24 06:01:34 |
Message-ID: | 162867790806232301y34210140w6aa735dac7cd2aeb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
2008/6/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)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.
(b) has one disadvantage - argument type is different than real
parameter - and internally it is little bit cleaner (doesn't need
changes in executor). So there is two forces in opposite. a) clean
function's declaration, b) clean function definition. This syntax is
limited - I am not able implement all cases of Oracle's decode
functions - but I hope it's good compromise between functionality and
simplicity.
note - variant b doesn't block multiple parameters as variadic - is
same case as a. array or not array is unimportant - I need different
types so I can choose what is first variadic argument and what is
second.
Academic question is using structured arrays - some like
create or replace function decode(s_value anyelement1, variadic
(s_value anyalement1, o_value anyelement)[])
returns anyelement as $$
select ($2[i]).o_value
from generate_subcripts($1,1) g(i)
where ($2[i]).s_value = $1;
$$ language sql;
regards
Pavel Stehule
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2008-06-24 06:13:55 | Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
Previous Message | Pavel Stehule | 2008-06-24 05:39:22 | Re: variadic function support |