Yeah, this doesn't actually work. You'll get this error:
ERROR: ALTER TYPE ... ADD cannot run inside a transaction block
ERROR: ALTER TYPE ... ADD cannot run inside a transaction block
"Reduce locking required for adding values to enum types (Andrew Dunstan, Tom Lane)
Previously it was impossible to run ALTER TYPE ... ADD VALUE in a transaction block unless the enum type was created in the same block.
Now, only references to uncommitted enum values from other transactions are prohibited."
https://www.postgresql.org/docs/devel/static/release-10.html...
Secondly, what are your thoughts on using enum generally? Would you recommend them in cases where you don't need to really optimise for narrower columns?
It's not that index structure specific atm, even though it could possibly be avoided for some types (e.g. hash, although there's considerable visibility issues to make that possible). Consider e.g. a btree index, if the deleted enum value ends up in an inner page, you really need to know how it compares to know where to descend to.
> Secondly, what are your thoughts on using enum generally? Would you recommend them in cases where you don't need to really optimise for narrower columns?
I like using them. There's cases where the transactional restrictions make it too problematic, but other than that I think the documentational advantage is substantial, besides just the width.