Re: FmgrInfo allocation patterns (and PL handling as staged programming) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date
Msg-id 2968353.1743962392@sss.pgh.pa.us
Whole thread Raw
In response to Re: FmgrInfo allocation patterns (and PL handling as staged programming)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Re: FmgrInfo allocation patterns (and PL handling as staged programming)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote
Next
From: Noah Misch
Date:
Subject: Re: datfrozenxid > relfrozenxid w/ crash before XLOG_HEAP_INPLACE