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

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Manipulating complex types as non-contiguous structures in-memory
Дата
Msg-id 54DE8B7B.2090707@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Manipulating complex types as non-contiguous structures in-memory  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: "multiple backends attempting to wait for pincount 1"
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0