Thread: patch: disable bypass of expand variadic for "ANY" variable function, format_array function for formatting with params in array

Hello

This patch disable bypassing of parameters for variadic function with
"ANY" type variadic parameter. Now - this functionality is just
broken. Because there are no any requests for fixing this issue, I
propose the most simply solution - just disable using this type of
variadic function when variadic variables are not expanded. Internally
it has impact to "format" function only. There are no possibility put
parameters in array. But this possibility can be useful. I cannot to
use overloading due ambiguous functions with "any" and "anyarray"
params. Solution can be new function "format_array" - that share code
with "format" function.

postgres=# select format_array('Hello %s, %1$s', array['World']);
    format_array
--------------------
 Hello World, World
(1 row)

postgres=# select format('Hello %s, %1$s', variadic array['World']);
ERROR:  function format(unknown, text[]) does not exist
LINE 1: select format('Hello %s, %1$s', variadic array['World']);
               ^
HINT:  No function matches the given name and argument types. You
might need to add explicit type casts.
postgres=# select format('Hello %s, %1$s', 'World');
       format
--------------------
 Hello World, World
(1 row)

Regards

Pavel Stehule

Attachment
Pavel Stehule <pavel.stehule@gmail.com> writes:
> This patch disable bypassing of parameters for variadic function with
> "ANY" type variadic parameter.

This seems completely silly.  If you think it's broken now (which I
don't particularly agree with: "does not do what you want in some corner
cases" is not "broken") then propose a fix.  Breaking it worse is not an
improvement.
        regards, tom lane



2012/9/8 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> This patch disable bypassing of parameters for variadic function with
>> "ANY" type variadic parameter.
>
> This seems completely silly.  If you think it's broken now (which I
> don't particularly agree with: "does not do what you want in some corner
> cases" is not "broken") then propose a fix.  Breaking it worse is not an
> improvement.

it is broken

format('%s %s", 'Hello', 'World') -- is ok -- case A
format('%s %s', variadic array['Hello', 'World']) -- fails  -- case B

Now, there are no possibility detect from function if there is a A
case or B case.

probably there are three fixes:

a) enhance FunctionCallInfoData by "expand_variadic" field - and then
different behave should be implemented in function,

b) enhance executor to use a updated FmgrInfo for every call of
function. FmgrInfo should be updated every call because fn_nargs can
be changed every call,

c) change mechanism how variadic parameters are passed to variadic
"any" function. Now we use FunctionCallInfoData. We can pass only
pointer to some structure with parameters enhanced about type info.
This mechanism can be same for A case and B case. And we can share
FmgrInfo - because there will be only one real parameter of type
internal. But this change is not compatible with current design. But
is a most simple probably and decrease difference between variadic
"any" functions and others variadic functions.

We can inplement a new datatype "any"[] - and this can be flag for new
implementation and "any" for old implementation. So there should not
be problem with compatibility.

Regards

Pavel


>
>                         regards, tom lane