From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
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-16 16:50:11 |
Message-ID: | 1887216.1673887811@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-16 17:11:58 | Re: Typo in 2.7 Aggregate Functions |
Previous Message | PG Doc comments form | 2023-01-16 15:50:08 | Typo in 2.7 Aggregate Functions |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-16 17:02:12 | Re: Make EXPLAIN generate a generic plan for a parameterized query |
Previous Message | Alexander Pyhalov | 2023-01-16 16:46:04 | Re: Inconsistency in vacuum behavior |