Re: Reorganize collation lookup time and place

Hi,

On 2018-12-13 14:50:53 -0500, Tom Lane wrote:
> 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.)

So, what's the plan here? Should the CF entry be closed?

Greetings,

Andres Freund