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
-
Use fast path in plpgsql's RETURN/RETURN NEXT in more cases.
- 9e3ad1aac524 9.5.0 cited
-
Add support for multiple kinds of external toast datums.
- 368202501539 9.4.0 cited