Hi,
On Thu, Mar 20, 2008 at 7:36 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
More to the point, it takes a capability away from the user without
actually solving the problem we need to solve, namely to guarantee
consistency between parent and child constraints. You can be sure
that there is someone out there who will complain that we've broken
his application when we disallow this, and we need to be able to
point to some positive benefit we got from it.
Agreed. So I think we need to implement the whole enchilada or nothing at all. We need to do the following for this:
* Add logic to disallow ADD CONSTRAINT ONLY to parent of an inheritance hierarchy
* Add logic to mark inherited constraints in the children:
This can be achieved by introducing a new bool "coninherited" attribute in pg_constraint. This will be set to true on only those check constraints that are added to children via the inheritance mechanism
* Add logic to disallow dropping inherited constraints directly on children
Obviously they will get dropped if a DROP CONSTRAINT is fired on the parent. with recurse set to true (this is the default behaviour)
* Modify the pg_dump logic to use the new pg_constraint based attribute logic for version 80300 (or should it be PG_VERSION_NUM 80400?) onwards. Infact the current logic to determine if a check constraint is inherited is to compare its name with the parent constraint name and the comment already mentions that we should make changes in pg_constraint to avoid this rudimentary way of determing the inheritance :).
Am important decision here is about adding a new attribute to pg_constraint as it is the only sane way of determining inherited constraints, but that will require an initdb. Comments?
Regards,
Nikhils
--
EnterpriseDB
http://www.enterprisedb.com