From: | Jeff Davis <jdavis-pgsql(at)empires(dot)org> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | Chris Travers <chris(at)travelamericas(dot)com>, PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: ENUM type |
Date: | 2005-07-26 21:05:17 |
Message-ID: | 42E6A58D.9080007@empires.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
Jim C. Nasby wrote:
>
> 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
> - no need to define RI
> - no need to manually map between ID and real values (though of course
> we should make it easy to get the ID too)
>
>
Yeah, you're right. But this is only in the case where someone cares
about using an int rather than a string type for some performance
reason. If they don't mind wasting a few bytes (and it's really only a
few bytes per record), then why not just use a check constraint when
defining the table (like Chris explains)?
> Hopefully someone on -hackers can shed light on what's required to clean
> up the parsing. One thing worth noting though, is that table definition
> is a relatively small part of doing a migration. Generally, it's
> application code that causes the most issues. Because of this, I think
> there would still be a lot of benefit to an enum type that didn't
> strictly follow the mysql naming/definition convention. In this case, it
> might be much easier to have an enum that doesn't allow you to define
> what can go into it at creation time; ie:
>
> CREATE TABLE ...
> blah ENUM NOT NULL ...
> ...
>
> ALTER TABLE SET ENUM blah ALLOWED VALUES(1, 2, 4);
Interesting. I'm not really sure exactly what syntax we want to use, but
as long as it gets the job done and is reasonable to implement.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-07-26 21:09:09 | Re: [HACKERS] Enticing interns to PostgreSQL |
Previous Message | Jeff Davis | 2005-07-26 20:56:11 | Re: [HACKERS] Enticing interns to PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-07-26 21:09:09 | Re: [HACKERS] Enticing interns to PostgreSQL |
Previous Message | Tom Lane | 2005-07-26 21:01:11 | Re: For review: Server instrumentation patch |