From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <jcflack@acm.org>
cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
In-reply-to: <2965818.1743960827@sss.pgh.pa.us>
References: <67F2B767.9040507@acm.org> <2965818.1743960827@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 06 Apr 2025 13:33:47 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2968352.1743962392.1@sss.pgh.pa.us>
Date: Sun, 06 Apr 2025 13:59:52 -0400
Message-ID: <2968353.1743962392@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2968353.1743962392%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Chapman Flack <jcflack@acm.org> writes:
>> I wonder, though, if there might be code in the wild, or even in corners
>> of the core I haven't looked in, where FmgrInfo structs aren't being used
>> that way, and could get reused for successive calls of one routine but
>> with, say, different nargs or argument types. That would seem odd but
>> I don't see that the documentation ever came right out and said not to.

> The only case I'm aware of that might require some thought is that the
> relcache caches FmgrInfo structs for the opclass support functions for
> each column of an index.  That seems like it's close enough to being
> just as specialized as a query callsite, but maybe not?

Actually, there is a case where you have to be careful if you support
polymorphic arguments: the element type of an anyarray argument can
change on-the-fly from one call to the next in the same query.  I
think this is only possible when you're fed pg_stats.most_common_vals
or one of its sibling columns, but that's enough to be a problem.
That's why all of our array-munging functions that use fn_extra to
cache type-dependent state are careful to check the element type
against the cache every single time.

			regards, tom lane