Thread

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

   Pavel Stehule <pavel.stehule@gmail.com> — 2012-09-08T15:10:51Z

   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
   

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

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-09-08T15:23:23Z

   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
   
   
   

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

   Pavel Stehule <pavel.stehule@gmail.com> — 2012-09-08T15:57:10Z

   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