D. Dante Lorenso wrote:
> 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.
Well since its configuration and not payload its nothing wrong with just
having the data in your repository as well and load it every time when
you roll out a new release.
Cheers
Tino
