Re: Allowing ALTER TYPE to change storage strategy - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allowing ALTER TYPE to change storage strategy
Date
Msg-id 9226.1582940133@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing ALTER TYPE to change storage strategy  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Allowing ALTER TYPE to change storage strategy  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: Allowing ALTER TYPE to change storage strategy  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I think we might check if there are any attributes with the given data
> type, and allow the change if there are none. That would still allow the
> change when the type is used only for things like function parameters
> etc. But we'd also have to check for domains (recursively).

Still has race conditions.

> One thing I haven't mentioned in the original message is CASCADE. It
> seems useful to optionally change storage for all attributes with the
> given data type. But I'm not sure it's actually a good idea, and the
> amount of code seems non-trivial (it'd have to copy quite a bit of code
> from ALTER TABLE).

You'd need a moderately strong lock on each such table, which means
there'd be serious deadlock hazards.  I'm dubious that it's worth
troubling with.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Allowing ALTER TYPE to change storage strategy
Next
From: Tom Lane
Date:
Subject: Re: Portal->commandTag as an enum