Re: enum bug

The post refers to the generic unmanageability of enums in genaral, it just
uses MySQL as a reference basis.
Google evil enum and you will find several articles that all say the same
thing.
To be specific,even in PostgreSQL, there is no easy way to delete enum
values once they exist, other than playing with system catalogs.
The point is, they are an archaic data type and it's a hell of a lot easier
to use Foreign Keys to insure integrity.
I've seen systems designed with an enum that has over 20 values associated
with it. It's insane to do that.

On Sun, Mar 13, 2016 at 10:08 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Melvin Davidson wrote:
>
> > Enums are evil!
> > http://www.lornajane.net/posts/2010/is-enum-evil
>
> ???
>
> This post is about MySQL's enums, which aren't really related to
> Postgres enums:
>
> "In order to change the allowed values of an enum column, we
> need to issue an alter table statement [...] Alter table
> actually creates a new table matching the new structure, copies
> all the data across, and then renames the new table to the right
> name."
>
> This is not at all how things happen in Postgres' enums.
>
>
> > enums are from before there were foreign keys
>
> In Postgres, ENUMs are pretty recent actually -- a lot newer than FKs:
>
> commit 57690c6803525f879fe96920a05e979ece073e71
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> AuthorDate: Mon Apr 2 03:49:42 2007 +0000
> CommitDate: Mon Apr 2 03:49:42 2007 +0000
>
> Support enum data types. Along the way, use macros for the values of
> pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing
> from Tom Lane.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.