Philip Warner <pjw@rhyme.com.au> writes:
> ISTM (with, perhaps, no basis (ISTMWPNB?)) that when allocating memory
> there are a couple of cases:
> You want it to be available:
> 1. until the end of the current call
> 2. at least until the next call
> 3. until TX end
> 4. forever
> ...etc.
Right, that's essentially what the various MemoryContexts are for.
> But if a relatively short list of allocation types can be created, then the
> palloc replacement can be passed an extra parameter (the 'allocation
> type'), and handle memory contexts appropriately.
I don't think that's a superior solution to passing a target
MemoryContext around. An allocation-type parameter would just mean an
extra lookup in some global array to find the appropriate MemoryContext.
That means even more global state, rather than less, and it's not as
extensible. Right now, if you have a need for a context with some
weird lifetime, you just make one and then delete it again later ---
the knowledge of the context's very existence, as well as lifetime,
is localized. In an allocation-type world you'd need to either add
a new allocation type code or figure out which existing category to
force-fit your context into.
In any case, this doesn't address the real practical problem, which is
going around and changing hundreds of routines and thousands of calls
thereto... I really *don't* want to add a memory management parameter
to everything in sight. Doesn't matter how the parameter is defined.
regards, tom lane
