On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Ali" == Ali Akbar <the.apaan@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
