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

From Japin Li
Subject Re: BUG #17610: Use of multiple composite types incompatible with record-typed function parameter
Date
Msg-id MEYP282MB16698A279FEBE7967E5B299DB6439@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: BUG #17610: Use of multiple composite types incompatible with record-typed function parameter  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17610: Use of multiple composite types incompatible with record-typed function parameter
List pgsql-bugs
On Fri, 09 Sep 2022 at 02:36, Tom Lane <tgl@sss.pgh.pa.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.



pgsql-bugs by date:

Previous
From: David Rowley
Date:
Subject: Re: huge memory of Postgresql backend process
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17611: SJIS conversion rule about duplicated characters differ from Windows