From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
Cc: | "Greg Mitchell" <gmitchell(at)atdesk(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Custom Data Type Question |
Date: | 2006-11-20 20:57:54 |
Message-ID: | 1164056275.3841.178.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2006-11-18 at 10:54 -0500, Andrew Dunstan wrote:
> > Your enum sounds good, apart from the hardcoded/compilation thing. That
> > is a data management nightmare AFAICS and so restricts the usefulness of
> > the solution.
> Simon, Tom Dunstan has submitted a patch for first class enum types that
> do not have the compilation requirement - it's in the queue for 8.3. You
> might want to review that.
Well, the link to previous discussion ends: How about being more
specific about what you are trying to accomplish? My thoughts:
IMHO we need to optimise FOREIGN KEY checks. One way of doing that is by
having enums that build the allowable values into the datatypes, I can
think of others. An overall evaluation of the various approaches should
be made before we settle on a specific one.
My requirements list would be to allow FOREIGN KEYS to
- be specified in SQL standard syntax
- work as fast as CHECK (col IN (1,2,3))
- use less memory and completely avoid any spill-to-disk nightmare(*)
- have the list of allowable values to be dynamically updateable,
automatically as INSERTs/DELETEs occur on the referenced table
- optimize without needing to change/reload database, just by adding
minimum number of statements (zero being the best)
(*) doesn't exist yet, thats why its a nightmare
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-11-20 20:58:41 | Re: Brazilian FAQ update |
Previous Message | Gurjeet Singh | 2006-11-20 20:55:21 | Re: psql: present working directory |