On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: >>>>>> "Ali" == Ali Akbar <the.ap...@gmail.com> writes: > > Ali> I think yes, it will be good. The alternative is restructuring > Ali> this paragraph in the SRF docs: > > >> The memory context that is current when the SRF is called is a > >> transient context that will be cleared between calls. This means > >> that you do not need to call pfree on everything you allocated > >> using palloc; it will go away anyway. However, if you want to > >> allocate any data structures to live across calls, you need to put > >> them somewhere else. The memory context referenced by > >> multi_call_memory_ctx is a suitable location for any data that > >> needs to survive until the SRF is finished running. In most cases, > >> this means that you should switch into multi_call_memory_ctx while > >> doing the first-call setup. > > Ali> The important part "However, if you want to allocate any data > Ali> structures to live across calls, you need to put them somewhere > Ali> else." is buried in the docs. > > Ali> But i think explicit warning is more noticeable for new > Ali> developer like me. > > I was thinking something like this, added just after that para: > > <warning> > <para> > While the actual arguments to the function remain unchanged between > calls, if you detoast the argument values (which is normally done > transparently by the > <function>PG_GETARG_<replaceable>xxx</replaceable></function> macro) > in the transient context then the detoasted copies will be freed on > each cycle. Accordingly, if you keep references to such values in > your <structfield>user_fctx</>, you must either copy them into the > <structfield>multi_call_memory_ctx</> after detoasting, or ensure > that you detoast the values only in that context. > </para> > </warning>
I'm OK with this. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
