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
Show quoted text
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