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.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
