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.
