<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px
0px0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It's
conceivablethat we could do something like adding an "isdead"<br /> column to pg_enum and making enum_in reject new
valuesthat're marked<br /> isdead. But I can't see that we'd ever be able to support true<br /> removal of an enum
valueat reasonable cost. And I'm not really sure<br /> where the use-case argument is for working hard on it.<br
/></blockquote></div><br/></div><div class="gmail_extra">Thanks for all your explanation!</div><div
class="gmail_extra">Wework a lot with enums and sometimes there are cases where we would like to be able to add a new
valueor rename an existing value (in a new transaction) - dropping isn't needed that much, but would be a
bonus.</div><divclass="gmail_extra">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
haveto use ugly hacks to make renaming/dropping work.</div><div class="gmail_extra">I didn't know implementing these
featureswould 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
providea patch myself unfortunately.</div><div class="gmail_extra">Hopefully at the commitfest at least the transaction
limitationwill/could be tackled - that would help us a lot already.</div><div class="gmail_extra"><br /></div><div
class="gmail_extra">Thanksfor your time!</div></div>
