Re: Custom Data Type Question

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

In response to

Responses

Browse pgsql-hackers by date

  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