On 2013-10-25 11:01:28 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > 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. > > > That sounds reasonable, and we have most of the infrastructure for it > > since the "indirect toast" thing got in. > > Oh really? I hadn't been paying much attention to that, but obviously > I better go back and study it.
Well, it has the infrastructure for adding further types of varattrib_1b_e types and for computing the size independently. So you can easily add a new type of toast datum. There still needs to be handling for it in tuptoaster.c et al, but that's not surprising ;) > > 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? > > Not yet. But it makes no sense to claim that a Datum could have a > reference that's longer-lived than the memory context it's in, so > I'm not sure the context reset case is really a problem. Given how short lived many of the contexts used for expression evaluation are, that might restrict the usefullness quite a bit. I think at the very least it has to be allowed that a Datum gets also used in child contexts. But that's already opens up the door for refcount leakage when the child context gets destroyed. I wonder if this needs mcxt.c/aset.c support to be useful. 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