Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Hi,

On 2018-06-06 01:01:49 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > In my understanding FunctionCallInfoData is basically per-call data,
> > whereas FmgrInfo is information about the function. It makes some sense
> > that ->context is in FunctionCallInfoData, after all it's used for
> > per-row data like the trigger context. But we don't really change the
> > collation of function invocations per-call. Thus I don't quite get why
> > FunctionCallInfoData contains information about it rather than FmgrInfo.
>
> [squint] I would say that the call collation is an argument, not a
> property of the function, and therefore is correctly located in
> FunctionCallInfoData.

I think it's not unreasonable to think of it that way, but it's really
not how it is used today. In pretty much all cases the collation is
known and determined at the time fmgr_info() is called (we also commonly
reuse FunctionCallInfoData structs).

And I think that's good, because we'd almost certainly be in trouble if
we didn't - if collation is used for input in data cached into fn_extra,
the caching the code largely doesn't go to the trouble to rebuild that
for a different collation.

> It's true that we often abuse fn_extra to hold data that's essentially
> call-site-dependent, but I don't think that's a good reason to push
> collation into FmgrInfo.

FmgrInfo really *is* call-site dependent, no? fn_extra, fn_mcxt, fn_expr
all are. I think it's more useful to view the FmgrInfo /
FunctionCallInfo data split as the separation between per-callsite and
per-call data. And I think it'd make much more sense to officially
treat collation as the former.

Greetings,

Andres Freund