From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Alter or rename enum value |
Date: | 2016-03-25 19:22:33 |
Message-ID: | 56F58FF9.101@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26/03/16 08:17, Jim Nasby wrote:
> On 3/24/16 10:27 PM, Tom Lane wrote:
>> It's conceivable that we could do something like adding an "isdead"
>> column to pg_enum and making enum_in reject new values that're marked
>> isdead. But I can't see that we'd ever be able to support true
>> removal of an enum value at reasonable cost. And I'm not really sure
>> where the use-case argument is for working hard on it.
>
> I wonder if we could handle this by allowing foreign keys on enum
> columns back to pg_enum. Presumably that means we'd have to treat
> pg_enum as a regular table and not a catalog table. Due to locking
> concerns I don't think we'd want to put the FKs in place by default
> either.
>
> I've certainly heard people avoiding ENUMs because of their
> limitations, so it'd be nice if there was a way to lift them.
Well, I use Enums extensively in Java.
However, I totally avoid using ENUMs in pg, due to their inflexibility!
Cheers,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2016-03-25 19:22:59 | Re: Alter or rename enum value |
Previous Message | Jim Nasby | 2016-03-25 19:17:00 | Re: Alter or rename enum value |