From: | Matthias Kurz <m(dot)kurz(at)irregular(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Alter or rename enum value |
Date: | 2016-03-25 08:13:50 |
Message-ID: | CAO=2mx6EOh6uQQ57Kv2z0x=kuyVbkEbwiY8R2h6VCPL=Fxe5wg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> 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.
>
Thanks for all your explanation!
We work a lot with enums and sometimes there are cases where we would like
to be able to add a new value or rename an existing value (in a new
transaction) - dropping isn't needed that much, but would be a bonus.
Right now you have to know which enum values you will use at the time
creating a table - but as many things change also requirements for a
database/schema/table/enum definition change. At the moment we have to use
ugly hacks to make renaming/dropping work.
I didn't know implementing these features would be that complex. As I am
not familiar with the code and don't have time to dig into it I won't be
able to provide a patch myself unfortunately.
Hopefully at the commitfest at least the transaction limitation will/could
be tackled - that would help us a lot already.
Thanks for your time!
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2016-03-25 08:16:21 | Re: Odd system-column handling in postgres_fdw join pushdown patch |
Previous Message | Thomas Munro | 2016-03-25 07:51:46 | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |