Laurenz Albe <laurenz.a...@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
