Re: Manipulating complex types as non-contiguous structures in-memory
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@postgreSQL.org
Date: 2015-02-10T23:01:14Z
Lists: pgsql-hackers
[ this is addressing a tangential point ... ] Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> * Although I said above that everything owned by a deserialized object >> has to live in a single memory context, I do have ideas about relaxing >> that. The core idea would be to invent a "memory context reset/delete >> callback" feature in mcxt.c. Then a deserialized object could register >> such a callback on its own memory context, and use the callback to clean >> up resources outside its context. > Being able to register a callback to be used on deletion of the context > would certainly be very nice and strikes me as pretty independent of the > rest of this. You've probably thought of this already, but registering > the callback should probably allow the caller to pass in a pointer to be > passed back to the callback function when the delete happens, so that > there's a place for the metadata to be stored about what the callback > function needs to clean up when it's called. Yeah, there would likely be use-cases for that outside of deserialized objects. I could submit a separate patch for that now, but I'm hesitant to add a mechanism without any use-case in the same patch. But maybe we could find a caller somewhere in the core aggregate code --- there are some aggregates that need cleanup callbacks already, IIRC, and maybe we could change them to use a memory context callback instead of whatever they're doing now. regards, tom lane
Commits
-
Use fast path in plpgsql's RETURN/RETURN NEXT in more cases.
- 9e3ad1aac524 9.5.0 cited
-
Add support for multiple kinds of external toast datums.
- 368202501539 9.4.0 cited