Chapman Flack <chap@anastigmatix.net> writes:
> By inspection of plperl and plpython, it looks like the canonical pattern
> for a PL using internal subtransactions is:
> save CurrentMemoryContext
> save CurrentResourceOwner
> BeginInternalSubTransaction
> reimpose the saved memory context
> // but not the saved resource owner
> ...
> (RollbackAnd)?ReleaseCurrentSubTransaction
> reimpose the saved memory context
> and the saved resource owner
> Therefore, during the subtransaction, its newly-established memory context
> is accessible as CurTransactionMemoryContext, but the caller can still use
> CurrentMemoryContext to refer to the same context it already expected.
> By contrast, the newly established resource owner is both the
> CurTransactionResourceOwner and the CurrentResourceOwner within the scope
> of the subtransaction.
> Is there more explanation of this pattern written somewhere than I have
> managed to find, and in particular of the motivation for treating the memory
> context and the resource owner in these nearly-but-not-quite matching
> ways?
You normally want a separate resource owner for a subtransaction, since
the main point of a subtransaction is to be able to clean up after errors
and release resources. What to do with CurrentMemoryContext is a lot more
specific to a particular PL. I don't want to speak to plperl and plpython
in particular, but plpgsql does it this way because it uses the same
function parsetree data structure and the same variable values throughout
execution of a function. You would not, say, want the function's local
variables to revert to previous values upon failure of a BEGIN block;
so they have to be kept in the same memory context throughout.
regards, tom lane
