From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Raj K" <raj(dot)indian(dot)08(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Reg: Custom Data Types in PostgreSQL |
Date: | 2008-11-22 06:07:03 |
Message-ID: | b42b73150811212207u7ba12730m6eb283997e18c4f7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 21, 2008 at 11:18 PM, Raj K <raj(dot)indian(dot)08(at)gmail(dot)com> wrote:
> Hi all,
> I am not an expert in DB. So please excuse, if the question is stupid.
>
> In PostgreSQL, we do support custom data types - say enum type.
> --> CREATE TYPE testtype AS ENUM {'test1', 'test2'};
> Now, I was wondering whether we should be using a different table or the
> enum itself for the same?
> --> CREATE TABLE testtypetable { testtype varchar(3) PRIMARY KEY, id
> serial };
> A new table would help in any modification of enum values, right?
> But then there is a mechanism to create this type, so there must be some
> extremely pertinent reason for having the same.
> Other than ease of use, I couldnt find any.
*) enums have an ordering built in to the type, so if you need to
order a lot of data it's much faster than to join out to get the
ordering criteria. This is admittedly a fairly narrow use case.
*) If you FK out on a integer key, your tables are full of integer
keys everywhere. Some people think that's great. I don't
*) If you FK out on a string key (in this case you might as well make
the enum text the primary key and drop the serial), you lose a little
bit in performance (particularly if the keys are large).
Nevertheless, I use this technique when enums are not appropriate.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Zagato | 2008-11-22 06:08:15 | Re: Interval Format |
Previous Message | Francois Figarola | 2008-11-22 05:45:07 | Re: Interval Format |