Re: Problem identifying constraints which should not be inherited

Hi,

On Thu, Mar 20, 2008 at 7:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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