Re: [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]

Hi,

On Tue, Apr 1, 2008 at 7:33 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:

> > I was taking a look at this patch to add the pg_dump related changes.
> Just
> > wanted to give you a heads up as this patch crashes if we run "make
> > installcheck". Seems there is an issue introduced in the CREATE TABLE
> > REFERENCES code path due to your patch (this is without my pg_dump
> changes
> > just to be sure). Looks like some memory overwrite issue. The trace is
> as
> > follows:
>
> Attached is a patch that fixes the problem... (it was debugging from
> an earlier version)
>

Yup, that fixes the problem.

PFA, a revised version of Alex' patch. I have added the relevant pg_dump
related changes too. As I mentioned earlier, I still don't know whether
Alex' syscache related changes are necessary, but I will leave it to the
patch reviewers to decide :)

This combined patch meets the following TODOs:

* Add logic to disallow ADD CONSTRAINT ONLY to parent of an inheritance
hierarchy

* Add logic to mark inherited constraints in the children:
This is achieved by introducing bool "conislocal" and int4 "coninhcount"
attributes in pg_constraint. The behaviour of these 2 attributes is pretty
similar to attislocal and attinhcount attributes in pg_attribute.

* 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 attributes
logic for versions above 80300 (or should it be PG_VERSION_NUM 80400?).

Please direct comments/feedback towards both me and Alex.

Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com