Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)

From: Tom Lane <[email-masked]>
Date: Sun, 06 Apr 2025 13:59:52 -0400

I wrote:
> Chapman Flack <[email-masked]> 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

---

From: Chapman Flack <[email-masked]>
Date: Sun, 6 Apr 2025 14:16:38 -0400

On 04/06/25 13:59, Tom Lane wrote:
> change on-the-fly from one call to the next in the same query.

Yuck! I had not guessed that.

Regards,
-Chap