Re: The flinfo->fn_extra question, from me this time. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: The flinfo->fn_extra question, from me this time.
Date
Msg-id 8955.1560648070@sss.pgh.pa.us
Whole thread Raw
In response to The flinfo->fn_extra question, from me this time.  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: The flinfo->fn_extra question, from me this time.
List 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 by date:

Previous
From: Chapman Flack
Date:
Subject: The flinfo->fn_extra question, from me this time.
Next
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)