> > 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!
