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

From Chapman Flack
Subject The flinfo->fn_extra question, from me this time.
Date
Msg-id 5D059584.6060408@anastigmatix.net
Whole thread Raw
Responses Re: The flinfo->fn_extra question, from me this time.
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: Improve handling of pg_stat_statements handling of bind "IN" variables
Next
From: Tom Lane
Date:
Subject: Re: The flinfo->fn_extra question, from me this time.