Re: The documentation for storage type 'plain' actually allows single byte header

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-17 08:05:34
Message-ID: 8591e9bbfe0891eed832c44f98f85c4c608a61a7.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

On Mon, 2023-01-16 at 11:50 -0500, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Eisentraut 2023-01-18 11:09:24 Re: Adding visual clues that accesskey exists
Previous Message Tom Lane 2023-01-16 17:11:58 Re: Typo in 2.7 Aggregate Functions

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-01-17 08:32:11 Re: Rethinking the implementation of ts_headline()
Previous Message Michael Paquier 2023-01-17 07:52:28 Re: Generating code for query jumbling through gen_node_support.pl