Re: ENUM type

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: "PostgreSQL advocacy" <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: ENUM type
Date: 2005-07-26 21:30:49
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3415C2EB2@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-general

Jim C Nasby:
> OK, but compare the amount of work you just described to the
simplicity
> of using an enum. Enum is much easier and simpler for a developer. Of
> course in most cases the MySQL way of doing it is (as has been
> mentioned) stupid, but done in the normal, normalized way it would
> remove a fair amount of additional work on the part of a developer:
>
> - no need to manually define seperate table
create table color (color text);
insert into color values ('red'); -- etc

> - no need to define RI
references color

> - no need to manually map between ID and real values (though of course
if you use color as p-key this is unnecessary

> we should make it easy to get the ID too)
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).

Merlin

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Jochem van Dieten 2005-07-26 22:11:47 Re: ENUM type
Previous Message Josh Berkus 2005-07-26 21:27:33 Re: SQL/PSM for 8.2 will offer ANSI/ISO, MySQL, and DB2 Compatibility

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2005-07-26 21:44:02 Re: back-end triggers front-end to update
Previous Message Adam O'Toole 2005-07-26 21:25:23 back-end triggers front-end to update