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

Hi,

On 2023-01-15 16:49:01 -0800, Andres Freund wrote:
> I don't see how we can fix this mess entirely without tracking the storage
> type a lot more widely. Most importantly in targetlists, as we use the
> targetlists to compute the tupledescs of executor nodes, which then influence
> where we build projections.
>
>
> Given that altering a column to PLAIN doesn't rewrite the table, we already
> have to be prepared to receive short or compressed varlenas, even after
> setting STORAGE to PLAIN.
>
> I think we should consider just reformulating the "furthermore it disables use
> of single-byte headers for varlena types" portion to say that short varlenas
> are disabled for non-toastable datatypes. I don't see much point in investing
> a lot of complexity making this a hard restriction. Afaict the only point in
> changing to PLAIN is to disallow external storage and compression, which it
> achieves eved when using short varlenas.
>
> The compression bit is a bit worse, I guess. We probably have the same problem
> with EXTERNAL, which supposedly doesn't allow compression - but I don't think
> we have code ensuring that we decompress in-line datums. It'll end up
> happening if there's other columns that get newly compressed or stored
> externally, but not guaranteed.

One way we could deal with it would be to force the tuple to be processed by
heap_toast_insert_or_update() when there's a difference between typstorage and
attstorage. I think to make that cheap enough to determine, we'd have to cache
that information in the relcache. I haven't thought it through, but I suspect
it'd be problematic to add a pg_type lookup to RelationBuildTupleDesc(),
leading to building that information on demand later.

Greetings,

Andres Freund