> > again, in this case the color should be the id and using a surrogate
key
> > is poor design. If that's too much typing you have the option of a
> > check constraint which is superior to enum in just about every way,
> > particularly if encapsulated into a domain (although inferior to RI
> > solution, IMO).
>
> Please go back through the original thread. The original comment was
> regarding adding an enum type that actually made sense; ie: it stored
an
> int in the base table that referenced a parent table. The original
> poster was arguing that enum didn't really buy anything over doing
that
> the manual method (create seperate table; fill that table with values;
> create base table with RI, and finally, make sure that everything that
> touches the base table can do mapping, or add a bunch of other stuff
to
> do the mapping automatically). My argument is that simply specifying
You're right, I did jump on this (mostly off-topic) thread. Also, I was
not aware that the enum did an id-id relationship internally.
Regardless, on the surface enum is essentially a check constraint.
Check constraints offer the same functionality and while marginally more
verbose they are much more powerful and more standard to boot.
Putting my advocacy hat on I'd rather highlight PostgreSQL's very well
implemented constraint system. However, if enum was implemented as
syntax sugar for a constraint in a similar way that serial is syntax
sugar for the default value then I suppose it would not be a bad idea.
Merlin
