Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Apr 19, 2021 at 12:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Au contraire. The reason that mode exists at all (for varlena types)
>> is to support data types that haven't been updated for TOAST.
> This kind of begs the question of whether you have the right idea
> about what PLAIN has always been understood to mean, and whether
> everyone understands it the same way. I formed my understanding of
> what PLAIN is understood to mean by reading the ALTER TABLE .. SET
> STORAGE documentation, and there's no real hint in there that this is
> some kind of backward-compatibility only feature.
That doco is explaining the users-eye view of it. Places addressed
to datatype developers, such as the CREATE TYPE reference page, see
it a bit differently. CREATE TYPE for instance points out that
All storage values other than plain imply that the functions of the
data type can handle values that have been toasted, as described in ...
> I think if I were designing this from scratch, I'd want one
> switch for whether it's OK to compress, with values meaning "yes,"
> "no," and "only if stored externally," a second switch for the
> *length* at which external storage should be used (so that I can push
> out rarely-used columns at lower size thresholds and commonly-used
> ones at higher thresholds), and a third for what should happen if we
> do the stuff allowed by the first two switches and the tuple still
> doesn't fit, with value meaning "fail" and "externalize anyway".
Yeah, I don't think the existing options for attstorage have much
to recommend them except backwards compatibility. But if we do
redesign them, I'd still say there should be a way for a data
type to say that it doesn't support these weird header hacks that
we've invented. The notion that short header doesn't cost anything
seems extremely Intel-centric to me.
regards, tom lane