RE: Imperfect solutions - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject RE: Imperfect solutions
Date
Msg-id ECEHIKNFIMMECLEBJFIGCENECAAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Imperfect solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Imperfect solutions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Imperfect solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> Let me make a suggestion.  Next time we have a partial fix for
> something, but don't want to add it, let's add the item on the TODO list
> under the heading "Imperfect Fixes," where we list items we have fixed
> but need more work.  This way, we will be able to give users a feature,
> but we will not forget to revisit the item and make a _perfect_ fix
> later.

The first thing you should add to that list is 'Inheritance of constraints'.
At the moment myself and Stephan are beavering away making it so that
constraints are recusively added and removed - however if ever we make a
pg_constraints catalog, and a one-to-many constraint->table mapping catalog,
all our code will need to be (minimally) changed.

Also, what about foreign keys?  At the moment it is incredibly complicated
to determine all the foreign keys on a table, what column(s) they're defined
over, what column(s) they reference and what their behaviour is.  And just
try writing code (like I am) that tries to drop them by name, let alone list
them!!!

Lastly - pg_dump can happily dump foreign keys as raw triggers, but the
perfect solution (methinks) would be to dump them as alter table add
constraints.  Makes it easier to move between different database products.

My 2c.

Chris



pgsql-hackers by date:

Previous
From: Michael Samuel
Date:
Subject: Re: Support for %TYPE in CREATE FUNCTION
Next
From: Tom Lane
Date:
Subject: Re: Imperfect solutions