Skip site navigation (1) Skip section navigation (2)

Re: Problem identifying constraints which should not be inherited

From: NikhilS <nikkhils(at)gmail(dot)com>
To: "Alex Hunsaker" <badalex(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Chris Fischer" <Chris(dot)Fischer(at)channeladvisor(dot)com>, pgsql-bugs(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problem identifying constraints which should not be inherited
Date: 2008-03-28 10:07:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
Hi Alex,

On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:

> On Thu, Mar 27, 2008 at 5:14 AM, NikhilS <nikkhils(at)gmail(dot)com> wrote:
> > * 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 :).
> >
> >
> Attached is a WIP patch I have been playing with in my spare time.  It
> should take care of the first 2.  It does nothing for pg_dump or set
> (not) null/set default.
> Note it has some gross points (see comment in
> src/backend/catalog/heap.c AddRelationRawConstraints) and the
> regression tests I added are not quite up to par (and probably a bit
> redundant).  But in the interest of saving work I thought i would post
> it.
I took a quick look and it seems to be on the lines of attislocal and
attinhcount which is a good thing. I am not sure about your syscache related
changes though and also about using enums for pg_constraint attributes which
deviates from other catalog specifications. Its good that you posted your
WIP here immediately or it would have caused duplication of efforts from my
side :)

I will take a look at the pg_dump related changes if you want. We will need
changes in flagInhAttrs() and in getTableAttrs() to query the backend for
these 2 attributes for post 80300 versions.

P.S Alvaro, I think this patch did not reach the mailing list and was
stalled due to size restrictions or something.


In response to


pgsql-hackers by date

Next:From: Tino WildenhainDate: 2008-03-28 10:17:18
Subject: Re: Surfacing qualifiers
Previous:From: Simon RiggsDate: 2008-03-28 09:44:42
Subject: Re: Commitfest patches

pgsql-bugs by date

Next:From: Eugen.KonkovDate: 2008-03-28 10:08:02
Subject: Documentation commenting does not work
Previous:From: Eugen.KonkovDate: 2008-03-28 09:56:41
Subject: Redundant explicit field name/types description while select from function with return type of record

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group