Re: Manipulating complex types as non-contiguous structures in-memory

On Thu, Feb 12, 2015 at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> My first thought is that we should form some kind of TOAST-like
>> backronym, like Serialization Avoidance Loading and Access Device
>> (SALAD) or Break-up, Read, Edit, Assemble, and Deposit (BREAD). I
>> don't think there is anything per se wrong with the terms
>> serialization and deserialization; indeed, I used the same ones in the
>> parallel-mode stuff. But they are fairly general terms, so it might
>> be nice to have something more specific that applies just to this
>> particular usage.
>
> Hm. I'm not against the concept, but those particular suggestions don't
> grab me.

Fair enough. I guess the core of my point is just that I suggest we
invent a name for this thing. "Serialize" and "deserialize" describe
what you are doing just fine, but the mechanism itself should be
called something, I think. When you say "varlena header" or "TOAST
pointer" that is a name for a very particular thing, not just a
general category of things you might do. If we replaced every
instance of "TOAST pointer" to "reference to where the full value is
stored", it would be much less clear, and naming all of the related
functions would be harder.

>> This is a clever
>> representation, but it's hard to wrap your head around, and I'm not
>> sure "primary" and "secondary" are the best names, although I don't
>> have an idea as to what would be better. I'm a bit confused, though:
>> once you give out a secondary pointer, how is it safe to write the
>> object through the primary pointer?
>
> It's no different from allowing plpgsql to update the values of variables
> of pass-by-reference types even though it has previously given out Datums
> that are pointers to them: by the time we're ready to execute an
> assignment, any query execution that had such a pointer is over and done
> with. (This implies that cursor parameters have to be physically copied
> into the cursor's execution state, which is one of a depressingly large
> number of reasons why datumCopy() has to physically copy a deserialized
> value rather than just copying the pointer. But otherwise it works.)

OK, I see. So giving out a secondary pointer doesn't necessarily
preclude further changes via the primary pointer, but you'd better be
sure that you don't try until such time as all of those secondary
references are gone.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company