Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 19, 2021 at 10:34 AM Amit Langote <amitlangote09(at)gmail(dot)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