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 по дате отправления: