| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Allowing ALTER TYPE to change storage strategy |
| Date: | 2020-02-29 01:35:33 |
| Message-ID: | 9226.1582940133@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-02-29 01:42:02 | Re: Portal->commandTag as an enum |
| Previous Message | Tomas Vondra | 2020-02-29 01:25:11 | Re: Allowing ALTER TYPE to change storage strategy |