Re: Reorganize collation lookup time and place

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

I am thinking of moving to commit 0001 (but not 0002) of
https://www.postgresql.org/message-id/20181009191802.ppt6lqcvkpjvkm76%40alap3.anarazel.de
which'd break some (but fewer) of the same place that'd be affected by
this.  The amount of memory saved for plpgsql and other places with lots
of expressoins is quite noticable, and it's a prerequisite for better
code generation and caching for JIT.  As that patch doesn't affect
DirectFunctionCall* etc, I'm not sure it's a sufficient argument to go
full breakage here, however.

Independent of that it still seems like putting stuff onto
every function caller that they don't need to deal with.

Greetings,

Andres Freund