Re: variadic function support

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
>

In response to

Browse pgsql-patches by date

  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