From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, suchithjn22(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: The documentation for storage type 'plain' actually allows single byte header |
Date: | 2023-01-15 23:41:22 |
Message-ID: | 1750674.1673826082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2023-01-15 18:08:21 -0500, Tom Lane wrote:
>> ri_newTupleSlot has the tupdesc we want, planSlot is a virtual slot
>> that has the bogus tupdesc, and for some reason heap_form_tuple is
>> getting called with planSlot's tupdesc not ri_newTupleSlot's.
> The way we copy a slot into a heap slot is to materialize the source slot and
> copy the heap tuple into target slot. Which is also what happened before the
> slot type abstraction (hence the problem also existing before that was
> introduced).
Hmm. For the case of virtual->physical slot, that doesn't sound
terribly efficient.
> I think it's fairly fundamental that copying between two slots assumes a
> compatible tupdescs.
We could possibly make some effort to inject the desired attstorage
properties into the planSlot's tupdesc. Not sure where would be a
good place.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-16 00:49:01 | Re: The documentation for storage type 'plain' actually allows single byte header |
Previous Message | Andres Freund | 2023-01-15 23:19:50 | Re: The documentation for storage type 'plain' actually allows single byte header |
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2023-01-16 00:01:50 | Re: doc: add missing "id" attributes to extension packaging page |
Previous Message | Michael Paquier | 2023-01-15 23:38:58 | Re: Extracting cross-version-upgrade knowledge from buildfarm client |