Re: The flinfo->fn_extra question, from me this time.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: The flinfo->fn_extra question, from me this time.
Дата
Msg-id 8955.1560648070@sss.pgh.pa.us
обсуждение исходный текст
Ответ на The flinfo->fn_extra question, from me this time.  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: The flinfo->fn_extra question, from me this time.  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> So please let me know if I seem to correctly understand the limits
> on its use.

> I gather that various extensions use it to stash various things. But
> (I assume) ... they will only touch fn_extra in FmgrInfo structs that
> pertain to *their own functions*. (Please say that's true?)

> IOW, it is assured that, if I am a language handler, when I am called
> to handle a function in my language, fn_extra is mine to use as I please ...

Yup.

> ... with the one big exception, if I am handling a function in my language
> that returns a set, and I will use SFRM_ValuePerCall mode, I have to leave
> fn_extra NULL before SRF_FIRSTCALL_INIT(), which plants its own gunk there,
> and then I can stash my stuff in gunk->user_fctx for the duration of that
> SRF call.

Yup.  (Of course, you don't have to use the SRF_FIRSTCALL_INIT
infrastructure.)

Keep in mind that in most contexts, whatever you cache in fn_extra
will only be there for the life of the current query.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: The flinfo->fn_extra question, from me this time.
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)