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