Re: Reorganize collation lookup time and place

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-12-13 15:05:40 +0100, Peter Eisentraut wrote:
>> On 12/12/2018 18:56, Andres Freund wrote:
>>> Why isn't this integrated into fmgr_info()?

>> fmgr_info() looks up stuff in pg_proc. pg_newlocale_...() looks up
>> stuff in pg_collation. There is no overlap between them.

> It looks up stuff necessary for calling a function, that doesn't fit
> looking up the collation necessary to do so too badly. A lot of the the
> changes you made are rote changes to each caller, taking the collation
> oid and expanding it with pg_newlocale_from_collation().

I'm not very thrilled with the idea of changing every single caller of
InitFunctionCallInfoData and related functions, especially when exactly
zero functional change ensues. We should work harder on avoiding that
code churn; extension developers will thank us.

>> There is also not necessarily a one-to-one correspondence between
>> function and collation lookup calls. For example, in some cases you
>> need to look up a sorting and a hashing functions, but only one
>> collation for both.

> That seems rare enough not to matter, performancewise.

I think it potentially does matter, but I also agree that it's not
the common case. Could we perhaps keep the API for the existing
functions the same, and introduce new functions alongside them
to be used by the small number of places where it matters?

(I've not looked at Peter's patch yet, so maybe I'm talking through
my hat. But we should set a pretty high value on avoiding code
churn in stuff as widely used as the fmgr interfaces.)

regards, tom lane