Alvaro Herrera wrote:
> D. Dante Lorenso wrote:
>> Or, here's another way to look at it ... make it easier to modify ENUM
>> datatypes because we all know that you will eventually need that feature
>> whether you males, females, and unknowns think so or not.
> Agreed. Let's keep in mind that the current ENUM implementation is
> completely new.
Here's a use case that I doubt too many are aware of ... what's unique
about ENUM is that the data for the ENUM becomes part of the schema of a
database.
This is actually something I like very much. I have systems where the
DEV and PROD databases are separate and must be synchronized when
pushing out new features. I currently use non-free tools to synchronize
just the schemas for both databases.
Often if a new row is added to a lookup table, that row doesn't make it
to the QA or PROD databases because it's part of the data of a table and
is not part of the schema. For data (like ENUM data) that should be
consistent across databases, it helps if it gets deployed with the
schema so that lookups will succeed properly.
-- Dante
