From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
cc: Andres Freund <andres@anarazel.de>, suchithjn22@gmail.com,
        pgsql-docs@lists.postgresql.org
Subject: Re: The documentation for storage type 'plain' actually allows single
 byte header
In-reply-to: <245d0f085c68fe0b877235d76a7c32a71454f39b.camel@cybertec.at>
References: 
 <167336599095.2667301.15497893107226841625@wrigleys.postgresql.org>
 <d99b3e0beebdde0741d28035aaea7f4af56fa050.camel@cybertec.at>
 <1698750.1673818827@sss.pgh.pa.us>
 <245d0f085c68fe0b877235d76a7c32a71454f39b.camel@cybertec.at>
Comments: In-reply-to Laurenz Albe <laurenz.albe@cybertec.at>
	message dated "Mon, 16 Jan 2023 14:07:48 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1887215.1673887811.1@sss.pgh.pa.us>
Date: Mon, 16 Jan 2023 11:50:11 -0500
Message-ID: <1887216.1673887811@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1887216.1673887811%40sss.pgh.pa.us>
Precedence: bulk

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Sun, 2023-01-15 at 16:40 -0500, Tom Lane wrote:
>> The documentation is correct, what is broken is the code.

> I see.  But what is the reason for that anyway?  Why not allow short varlena
> headers if TOAST storage is set to PLAIN?

The original motivation for that whole mechanism was to protect data
types for which the C functions haven't been upgraded to support
non-traditional varlena headers.  So I was worried that this behavior
would somehow break those cases (which still exist, eg oidvector and
int2vector).  However, the thing that actually marks such a datatype
is that pg_type.typstorage is PLAIN, and as far as I can find we do
still honor that case in full.  If that's the case then every tupdesc
we ever create for such a column will say PLAIN, so there's no
opportunity for the wrong thing to happen.

So maybe it's okay to move the goalposts and acknowledge that setting
attstorage to PLAIN isn't a complete block on applying toast-related
transformations.  I wonder though whether short-header is the only
case that can slide through.  In particular, for "INSERT ... SELECT
FROM othertable", I suspect it's possible for a compressed-in-line
datum to slide through without decompression.  (We certainly must
fix out-of-line datums, but that doesn't necessarily mean we undo
compression.)  So I'm not convinced that the proposed wording is
fully correct yet.

			regards, tom lane