On 2013-10-25 11:01:28 -0400, Tom Lane wrote:
> Andres Freund <andres@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
