Hi, On Thu, Mar 20, 2008 at 7:36 PM, Tom Lane <[EMAIL PROTECTED]> 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
