Re: BUG #17610: Use of multiple composite types incompatible with record-typed function parameter

On Fri, 09 Sep 2022 at 02:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The reason is that the core parser's callback APIs allow plpgsql
> to deal with the "x.f1" construct as a unit, and it can handle
> the varying actual type of "x" internally. However, the callback
> APIs are not equivalently intelligent about "$N" references.
> Those get resolved as Params of type RECORD (with a separate
> FieldSelect on top, in this case), and then we don't have enough
> context to figure out which record type is involved, or indeed
> that different record types could be involved.
>
> My proposed patch fixes things for the case where the caller
> passes a named composite type, but not for passing an anonymous
> record, as you can see in the test cases in the attached.
> (If you don't apply the code patch, the last getf2() call also
> fails, matching the OP's complaint. But the getf1() calls
> still work.)
>
> So really the way we ought to fix this is to upgrade the parser
> APIs so that plpgsql could deal with "$1.f1" as a unit. But
> that seems like a lot of work, and it would certainly not be
> back-patchable.
>

Tested and looks good!

> In the meantime, I'm uncertain whether we want this change or not.
> Duplicating the function cache entry for each composite type
> that gets passed during a session is a pretty expensive solution,
> especially if it only fixes cases that are being written in a
> semi-deprecated fashion.
>

Yeah, maybe we can document it. Or is there any way for the user to
discard the cache entry?

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.