On 2013-10-25 10:18:27 -0400, Tom Lane wrote: > I think the right way to attack it is to create some way for a Datum > value to indicate, at runtime, whether it's a flat value or an in-memory > representation. Any given function returning the type could choose to > return either representation. The datatype would have to provide a way > to serialize the in-memory representation, when and if it came time to > store it in a table. To avoid breaking functions that hadn't yet been > taught about the new representation, we'd probably want to redefine the > existing DETOAST macros as also invoking this datatype flattening > function, and then you'd need to use some new access macro if you wanted > visibility of the non-flat representation. (This assumes that the whole > thing is only applicable to toastable datatypes, but that seems like a > reasonable restriction.)
That sounds reasonable, and we have most of the infrastructure for it since the "indirect toast" thing got in. > Another thing that would have to be attacked in order to make the > plpgsql-variable case work is that you'd need some design for copying such > Datums in-memory, and perhaps a reference count mechanism to optimize away > unnecessary copies. Your idea of tying the optimization to the nested > function call scenario would avoid the need to solve this problem, but > I think it's too narrow a scope to justify all the other work that'd be > involved. I've thought about refcounting Datums several times, but I always got stuck when thinking about how to deal memory context resets and errors. Any ideas about that? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
