Re: ERROR: type of parameter 1 (fruit2) does not match that when preparing the plan (fruit1)

On Sun, May 1, 2022 at 10:08 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Sun, May 1, 2022 at 8:44 AM d <dchuck(at)yurfish(dot)com> wrote:
> >> CREATE OR REPLACE FUNCTION record_to_form_data(p_r record)
>
> > Not a bug, it is a documented limitation.
>
> FWIW, it does seem to work as desired if you declare the argument as
> "anyelement".
>

+1

>
> Maybe we could improve this situation by treating a "record" parameter
> as polymorphic, though that might cause some odd inconsistencies with
> plpgsql's historical treatment of "record" local variables.
>
>
The extent of needing to treat "record" as polymorphic-like seems like it
would be limited to resolve_polymorphic_argtype in funcapi.c. Namely, in
computing the hash key for the compiled hash entry for the function.
Similar to how we append the trigger oid in compute_function_hashkey in
pl.compile (which ultimately calls the former) so trigger invocations
become per-table.

David J.