Re: Allowing ALTER TYPE to change storage strategy

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allowing ALTER TYPE to change storage strategy
Date: 2020-03-05 19:05:13
Message-ID: 20200305190513.y4j3ckkvpzrgiy2y@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Mar 04, 2020 at 06:56:42PM -0500, Tom Lane wrote:
>I wrote:
>> 3. Drop the ability for ALTER TYPE to promote from PLAIN to not-PLAIN
>> typstorage, and adjust the typcache so that it only remembers boolean
>> toastability not the specific toasting strategy. Then the cache is
>> still immutable so no need for update logic.
>> I'm kind of liking #3, ugly as it sounds, because I'm not sure how
>> much of a use-case there is for the upgrade-from-PLAIN case.
>> Particularly now that TOAST is so ingrained in the system, it seems
>> rather unlikely that a production-grade data type wouldn't have
>> been designed to be toastable from the beginning, if there could be
>> any advantage to that. Either #1 or #2 seem like mighty high prices
>> to pay for offering an option that might have no real-world uses.
>Here's a v5 based on that approach. I also added some comments about
>the potential race conditions involved in recursing to domains.

Well, I don't know what to say, really. This very thread started with me
explaining how I've repeatedly needed a way to upgrade from PLAIN, so I
don't quite agree with your claim that there's no use case for that.

Granted, the cases may be my faults - sometimes I have not expected the
type to need TOAST initially, and then later realizing I've been wrong.
In other cases I simply failed to realize PLAIN is the default value
even for varlena types (yes, it's a silly mistake).

FWIW I'm not suggesting you go and implement #1 or #2 for me, that'd be
up to me I guess. But I disagree there's no use case for it, and #3
makes this featuer useless for me.


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2020-03-05 19:18:12 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Previous Message Ibrar Ahmed 2020-03-05 19:05:00 Re: more ALTER .. DEPENDS ON EXTENSION fixes