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

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема The flinfo->fn_extra question, from me this time.
Дата
Msg-id 5D059584.6060408@anastigmatix.net
обсуждение исходный текст
Ответы Re: The flinfo->fn_extra question, from me this time.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi hackers,

I see evidence on this list that it's sort of a rite of passage
to ask the flinfo->fn_extra question, and my time has come.

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 ...

... 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.

Does that seem to catch the essentials?

Thanks,
-Chap


p.s.: noticed in fmgr/README: "Note that simple "strict" functions can
ignore both isnull and args[i].isnull, since they won't even get called
when there are any TRUE values in args[].isnull."

I get why a strict function can ignore args[i].isnull, but is the part
about ignoring isnull a mistake? A strict function can be passed all
non-null arguments and still return null if it wants to, right?



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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Improve handling of pg_stat_statements handling of bind "IN" variables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: The flinfo->fn_extra question, from me this time.