Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?
Date
Msg-id 8282.1528298253@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 6/6/18 09:06, Andres Freund wrote:
>> 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.

> I think there are really three sets of information: catalog lookup
> information, per query/expression information (such as collation), and
> per-call information.  But we only have two places to put things, so it
> might look a bit odd.

> Nothing wrong with considering changes, of course.

Well, I still say this is an ad-hoc, unprincipled semantics change.
If we're going to buy into FmgrInfo being call site dependent,
we should go all the way.  Why not move nargs there (or get rid of it,
isn't it redundant with fn_nargs?), and possibly the context pointer?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: PATCH pass PGOPTIONS to pg_regress
Next
From: Nico Williams
Date:
Subject: Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints