Robert Haas <robertmh...@gmail.com> writes: > On Mon, Apr 19, 2021 at 10:34 AM Amit Langote <amitlangot...@gmail.com> wrote: >> After 86dc90056, the new tuple is computed with the target table's >> actual TupleDesc, so the new value respects the column's attstorage, >> which makes me think the new behavior is not wrong.
> I would not have expected SET STORAGE PLAIN to disable the use of > short varlena headers. Au contraire. The reason that mode exists at all (for varlena types) is to support data types that haven't been updated for TOAST. Perhaps that's now the empty set, but it's not really our job to take away the capability. If you really want MAIN you should say that, not quibble that PLAIN doesn't mean what it's always been understood to mean. I don't think that this behavior quite breaks such data types, because if you actually have a type like that then you've set typstorage = PLAIN and we will not allow there to be any tupdescs in the system that differ from that. The issue is just that if you set a particular column of an otherwise-toastable type to be PLAIN then we're not terribly rigorous about enforcing that, because values that have been toasted can get into the column without being fully detoasted. (I've not checked, but I suspect that you could also get a compressed or toasted-out-of-line value into such a column if you tried hard enough.) Related to this is that when you update some other column(s) of the table, we don't try to force detoasting of existing values in a column recently set to PLAIN. Personally I think that's fine, so it means that the lack of rigor is inherent. regards, tom lane