Gregory Stark <stark@enterprisedb.com> writes:
> I do have an objection though: TOAST data. Even were the bufmgr to be
> provided with a mechanism to find a data type conversion function I
> don't see what it would do about a toasted datum.
Urgh, that *is* a nasty thought :-(
Out-of-line datums aren't the only issue, either: consider inline
compressed datums. A data representation change, even one that is known
not to increase the ordinary uncompressed size of the datum, could
easily render it slightly less compressible, resulting in a risk that
the tuple doesn't fit on the page anymore. It hardly seems practical
(maybe not even possible) to guarantee that this cannot happen.
So maybe we are up against the conclusion that in-place updates cannot
support datatype representation changes, at least not for toastable
datatypes. We could still handle 'em by the expedient suggested
upthread for user-defined types, ie the "new representation" is treated
as a whole new type. That's not terribly appetizing though; I had
expected we could be more efficient for the case of changes in built-in
types.
regards, tom lane