Interest in supporting enum value deletion in migrations?

[rolftimmermans]

An operation that is not natively supported in PostgreSQL is enum value deletion. It appears this is technically complicated to implement in the database engine.

However to clean up the database schema it still can be useful to do. The common workaround is to create a new enum with the desired values (omitting the values that should be deleted) and updating the type of all columns in all tables referencing the enum. This does not work in all cases; for example, changing the type of columns in views is not supported. And obviously the value to be dropped must not be in use in the data.

For me it seems incredibly useful to support this in a Sequel migration, but the implementation is non-trivial and may fail in some cases, which Sequel can probably not detect ahead of time.

Is there interest in adding it to Sequel? I'd be happy to submit a PR if so.

[jeremyevans]

I'm sorry, but I'm not interested in supporting this in Sequel. My recommendation is to avoid the use of enums in any case where you would need to delete an enum value. This includes pretty much all cases where you would want to add a value to an enum in a migration, since generally users want migrations that are reversible. Unless you are 100% sure you will never need to modify the enum values, I think using an enum is a bad choice, and I would guess few people can predict the future with 100% accuracy.

At my job, we have numerous enum types due to preexisting design decisions. When we get to a case where we want to add the value, we generally switch the column type to text and add a CHECK constraint for the allowed values.

[rolftimmermans]

Thanks for your response! No worries, this is why I wanted to check beforehand.
Personally I think enums are generally fine, the only downside seems to be that deletions are difficult. Appreciate your perspective though!