Обсуждение: fix - function call with variadic parameter for type "any"

Hello,

Our implementation of variadic parameters are not complete. The
support of "any" type is incomplete. Modificator VARIADIC for funccall
parameters needs transformation from ArrayExpr to standard parameters
list.

==current behave==
postgres=# select variadic_demo2(10,'Petr',20,20,30);
NOTICE:  arg(0) = 10
NOTICE:  arg(1) = Petr
NOTICE:  arg(2) = 20
NOTICE:  arg(3) = 20
NOTICE:  arg(4) = 30
 variadic_demo2
----------------

(1 row)

Time: 3,245 ms
postgres=# select variadic_demo2(10,'Petr',20, variadic array[10,20]);
NOTICE:  arg(0) = 10
NOTICE:  arg(1) = Petr
NOTICE:  arg(2) = 20
NOTICE:  arg(3) = {10,20}
 variadic_demo2
----------------

(1 row)

==fixed behave==

Time: 1,287 ms
postgres=# select variadic_demo2(10,'Petr',20,20,30);
NOTICE:  arg(0) = 10
NOTICE:  arg(1) = Petr
NOTICE:  arg(2) = 20
NOTICE:  arg(3) = 20
NOTICE:  arg(4) = 30
 variadic_demo2
----------------

(1 row)

Time: 0,994 ms
postgres=# select variadic_demo2(10,'Petr',20, variadic array[10,20]);
NOTICE:  arg(0) = 10
NOTICE:  arg(1) = Petr
NOTICE:  arg(2) = 20
NOTICE:  arg(3) = 10
NOTICE:  arg(4) = 20
 variadic_demo2
----------------

(1 row)

regards
Pavel Stehule

Pavel Stehule <pavel.stehule@gmail.com> writes:
> Our implementation of variadic parameters are not complete. The
> support of "any" type is incomplete. Modificator VARIADIC for funccall
> parameters needs transformation from ArrayExpr to standard parameters
> list.

I don't think I agree with this change.  The point of an ANY function
is that the function is going to do its own coping with the presented
arguments.  This patch takes away the flexibility to do that and instead
enforces one very restrictive view of what the intended behavior is.
        regards, tom lane

2009/4/2 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> Our implementation of variadic parameters are not complete. The
>> support of "any" type is incomplete. Modificator VARIADIC for funccall
>> parameters needs transformation from ArrayExpr to standard parameters
>> list.
>
> I don't think I agree with this change.  The point of an ANY function
> is that the function is going to do its own coping with the presented
> arguments.  This patch takes away the flexibility to do that and instead
> enforces one very restrictive view of what the intended behavior is.

ok, but then an function have to be noticed about using VARIADIC
parameter's modificator.

actually, there isn't any difference between a) and b)

a) select somevariadicwithany(10);
b) select somevariadicwithany(variadic 10);

in this case the keyword VARIADIC is ignored.

regards
Pavel Stehule

>
>                        regards, tom lane
>

Pavel Stehule <pavel.stehule@gmail.com> writes:
> actually, there isn't any difference between a) and b)

> a) select somevariadicwithany(10);
> b) select somevariadicwithany(variadic 10);

> in this case the keyword VARIADIC is ignored.

Well, in my mind what the VARIADIC keyword does is it prevents the parser
from building an ARRAY[] expression around the remaining parameters.
Which would be incorrect for a VARIADIC ANY function because such a
function presumably doesn't want to force all the actual arguments
to be the same type --- if it did, it could use VARIADIC ANYARRAY.

VARIADIC ANY basically exists to allow an ANY-argument function to
accept any number of ANY parameters.  As such, PG_NARGS() is all it
really needs to know, plus the already-existing support for obtaining
the parameters' actual datatypes.
        regards, tom lane

2009/4/2 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> actually, there isn't any difference between a) and b)
>
>> a) select somevariadicwithany(10);
>> b) select somevariadicwithany(variadic 10);
>
>> in this case the keyword VARIADIC is ignored.
>
> Well, in my mind what the VARIADIC keyword does is it prevents the parser
> from building an ARRAY[] expression around the remaining parameters.
> Which would be incorrect for a VARIADIC ANY function because such a
> function presumably doesn't want to force all the actual arguments
> to be the same type --- if it did, it could use VARIADIC ANYARRAY.
>
> VARIADIC ANY basically exists to allow an ANY-argument function to
> accept any number of ANY parameters.  As such, PG_NARGS() is all it
> really needs to know, plus the already-existing support for obtaining
> the parameters' actual datatypes.
>
>

it can be good idea - I see only one disadvantage.

I will have two functions with same body - but it isn't significant problem

regards
Pavel Stehule

                       regards, tom lane
>