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

Jim Nasby <jim.nasby@bluetreble.com>

From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Martijn van Oosterhout <kleptog@svana.org>, Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-02-13T23:40:43Z
Lists: pgsql-hackers
On 2/13/15 2:04 AM, Martijn van Oosterhout wrote:
> On Thu, Feb 12, 2015 at 08:52:56AM -0500, Robert Haas wrote:
>>> > >BTW, I'm not all that thrilled with the "deserialized object" terminology.
>>> > >I found myself repeatedly tripping up on which form was serialized and
>>> > >which de-.  If anyone's got a better naming idea I'm willing to adopt it.
>> >
>> >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.
> The words that sprung to mind for me were: packed/unpacked.

+1

After thinking about it, I don't think having a more distinctive name 
(like TOAST) is necessary for this feature. TOAST is something that's 
rather visible to end users, whereas packing would only matter to 
someone creating a new varlena type.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


Commits

  1. Use fast path in plpgsql's RETURN/RETURN NEXT in more cases.

  2. Add support for multiple kinds of external toast datums.