Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> ... That means that the contained fields had better not be
>> out-of-line TOAST value references, because there's no way to keep track
>> of them and keep from deleting the referenced value too soon.
> Why wouldn't we handle this just like we do when we build an array from
> elemental datums (i.e. allocate sufficient space and copy the individual
> datums into the structure)?
Well, the problem is that there are tuples and there are tuples. We do
*not* want to force expansion of TOAST references every time we build an
intermediate tuple to return up one level in a plan. That would cost
gobs of memory, and it's possible the expanded value will never actually
be used at all (eg, the row might fail a join qual further up the plan).
Ideally the forced expansion should only occur if a composite-type tuple
is actually about to be stored on disk. Maybe this says that the
toaster routines are the right place to take care of it after all, but
I'm not quite sure where it should go.
BTW, you could argue that TOAST references in a constructed array ought
not be expanded until/unless the array gets written to disk, too. But
the expense of scanning a large array on the off chance there's some
TOAST references in there might dissuade us from doing that. (Hmm ...
maybe use a flag bit in the array flag word?)
>> The other point was that what's actually returned at the moment from a
>> function-returning-tuple is a Datum that contains a pointer to a
>> TupleTableSlot, not a pointer to a datum of this kind.
> If you had something akin to arrayin/arrayout, would this still need to
> be changed?
I don't see the connection. This is an internal representation either
way, and there's no point at which one would want to invoke an I/O
routine.
regards, tom lane