From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Laurenz Albe <laurenz.albe@cybertec.at>, suchithjn22@gmail.com,
        pgsql-docs@lists.postgresql.org
Subject: Re: The documentation for storage type 'plain' actually allows single
 byte header
In-reply-to: <20230115230320.d3mtlzek6dv7mgxx@awork3.anarazel.de>
References: 
 <167336599095.2667301.15497893107226841625@wrigleys.postgresql.org>
 <d99b3e0beebdde0741d28035aaea7f4af56fa050.camel@cybertec.at>
 <1698750.1673818827@sss.pgh.pa.us>
 <20230115230320.d3mtlzek6dv7mgxx@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sun, 15 Jan 2023 15:03:20 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1747091.1673824101.1@sss.pgh.pa.us>
Date: Sun, 15 Jan 2023 18:08:21 -0500
Message-ID: <1747092.1673824101@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1747092.1673824101%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2023-01-15 16:40:27 -0500, Tom Lane wrote:
>> The documentation is correct, what is broken is the code.  I'm not
>> sure when we broke it

> I've not thought through this fully. But after a first look, this might be
> hard to fix without incuring a lot of overhead / complexity.

It appeared to me that it was failing at this step in
ExecGetInsertNewTuple:

        if (relinfo->ri_newTupleSlot->tts_ops != planSlot->tts_ops)
        {
            ExecCopySlot(relinfo->ri_newTupleSlot, planSlot);
            return relinfo->ri_newTupleSlot;
        }

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.  I'm
not quite sure if this is just a thinko somewhere or there's a
deficiency in the design of the slot APIs.

The UPDATE path seems to work fine, btw.

			regards, tom lane