Hi, On 2018-06-06 01:01:49 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.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
