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

I wrote:
> Chapman Flack <jcflack(at)acm(dot)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