Thread: Polymorphic functions' weird behavior

Hello
We've come across  the following issue with Polymorphic functions:

CREATE OR REPLACE FUNCTION "array_to_set" (vaarray anyarray) RETURNS
SETOF anyelement AS
$body$
BEGIN
   FOR I IN COALESCE(ARRAY_LOWER(VAARRAY, 1), 1) ..
COALESCE(ARRAY_UPPER(VAARRAY, 1), 0) LOOP
       RETURN NEXT VAARRAY[I];
   END LOOP;
END
$body$
LANGUAGE 'plpgsql' SECURITY INVOKER;


 > select * from array_to_set(array[1,2,3]);
array_to_set
--------------
           1
           2
           3
(3 rows)


Now we change SECURITY INVOKER clause to SECURITY DEFINER and voila:

 > select * from array_to_set(array[1,2,3]);
ERROR:  could not determine actual argument type for polymorphic
function "array_to_set"

Though explainable this is absolutely strange since logically security
rules and polymorphism are irrelevant.

regards, Viatcheslav

Viatcheslav Kalinin <vka@ipcb.net> writes:
> Now we change SECURITY INVOKER clause to SECURITY DEFINER and voila:

>>> select * from array_to_set(array[1,2,3]);
> ERROR:  could not determine actual argument type for polymorphic
> function "array_to_set"

Wow, apparently you're the first person ever to try that, because it's
never worked in any release since polymorphism was introduced :-(.
Thanks for the report!

The fix is pretty easy if you need it now:

Index: fmgr.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/fmgr/fmgr.c,v
retrieving revision 1.102
diff -c -r1.102 fmgr.c
*** fmgr.c    4 Oct 2006 00:30:01 -0000    1.102
--- fmgr.c    31 Jul 2007 15:39:29 -0000
***************
*** 793,798 ****
--- 793,799 ----

          fmgr_info_cxt_security(fcinfo->flinfo->fn_oid, &fcache->flinfo,
                                 fcinfo->flinfo->fn_mcxt, true);
+         fcache->flinfo.fn_expr = fcinfo->flinfo->fn_expr;

          tuple = SearchSysCache(PROCOID,
                                 ObjectIdGetDatum(fcinfo->flinfo->fn_oid),


            regards, tom lane

Tom Lane wrote:
> The fix is pretty easy if you need it now

Thanks for the update, Tom.
Another little issue with that function. I cannot make it
accept NULL as an argument. It won't normally accept NULL
reporting an appropriate error that it cannot determine
argument type, nor will it accept it if I make the
function STRICT, nor can I handle it inside the function
since it isn't actually called. Thus I always get the
error which is not desirable behavior. Any way around it?

regards, Viatcheslav

"Vyacheslav Kalinin" <vka@ipcb.net> writes:
> Another little issue with that function. I cannot make it
> accept NULL as an argument.

You'd have to cast the NULL to some specific array type.

            regards, tom lane

Tom Lane wrote:
>
> You'd have to cast the NULL to some specific array type.
>
> regards, tom lane
Unfortunately I can't do that (well, in fact it would be pretty
inconvenient) because the function is called from other plpgsql function
and I cannot be sure if it will be called with NULL or not. Anyway I
seem to resolved the problem by writing another doing-nothing-at-all
function with the same name and "unknown' argument type.

regards, Viatcheslav