Hi, On 2018-12-13 14:50:53 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.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