Re: Manipulating complex types as non-contiguous structures in-memory - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Manipulating complex types as non-contiguous structures in-memory
Date
Msg-id 54DE8B7B.2090707@BlueTreble.com
Whole thread Raw
In response to Re: Manipulating complex types as non-contiguous structures in-memory  (Martijn van Oosterhout <kleptog@svana.org>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: "multiple backends attempting to wait for pincount 1"
Next
From: Jim Nasby
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0