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.
|
Список | 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 по дате отправления: