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

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