From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: suchithjn22@gmail.com
Cc: pgsql-docs@lists.postgresql.org
Subject: Re: The documentation for storage type 'plain' actually allows single byte header
Date: Tue, 17 Jan 2023 09:05:34 +0100
Message-ID: <8591e9bbfe0891eed832c44f98f85c4c608a61a7.camel@cybertec.at> (raw)
In-Reply-To: <1887216.1673887811@sss.pgh.pa.us>
References: <167336599095.2667301.15497893107226841625@wrigleys.postgresql.org>
<d99b3e0beebdde0741d28035aaea7f4af56fa050.camel@cybertec.at>
<1698750.1673818827@sss.pgh.pa.us>
<245d0f085c68fe0b877235d76a7c32a71454f39b.camel@cybertec.at>
<1887216.1673887811@sss.pgh.pa.us>
On Mon, 2023-01-16 at 11:50 -0500, Tom Lane wrote:
> 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.
I see, thanks for the explanation.
Since the only storage format I have ever had use for are EXTENDED
and EXTERNAL, it is not very important for me if PLAIN supports short
headers or not. Since single-byte headers are part of the TOAST
mechanism (and documented as such), it makes sense to disable them
in PLAIN. Then the documentation could describe PLAIN as
"skip all TOAST processing".
So we should probably go with the simplest fix that restores
consistency.
Yours,
Laurenz Albe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: laurenz.albe@cybertec.at, tgl@sss.pgh.pa.us, 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: <8591e9bbfe0891eed832c44f98f85c4c608a61a7.camel@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox