Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?
Дата
Msg-id 8282.1528298253@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: PATCH pass PGOPTIONS to pg_regress
Следующее
От: Nico Williams
Дата:
Сообщение: Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints