Re: Manipulating complex types as non-contiguous structures in-memory
Martijn van Oosterhout <kleptog@svana.org>
From: Martijn van Oosterhout <kleptog@svana.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-02-13T08:04:54Z
Lists: pgsql-hackers
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. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
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