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