Re: Add generate_series(numeric, numeric)
От | Andrew Gierth |
---|---|
Тема | Re: Add generate_series(numeric, numeric) |
Дата | |
Msg-id | 87d27lpkmh.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Add generate_series(numeric, numeric) (Ali Akbar <the.apaan@gmail.com>) |
Ответы |
Re: Add generate_series(numeric, numeric)
|
Список | pgsql-hackers |
>>>>> "Ali" == Ali Akbar <the.apaan@gmail.com> writes: Ali> I think yes, it will be good. The alternative is restructuringAli> 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 surviveuntil 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 dataAli> structures to live across calls, you need to put themsomewhereAli> else." is buried in the docs. Ali> But i think explicit warning is more noticeable for newAli> 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 detoastthe argument values (which is normally done transparently by the <function>PG_GETARG_<replaceable>xxx</replaceable></function>macro) in the transient context then the detoasted copieswill 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> -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: