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: | d3c4af540803280307n37f6536fn28892dae1bf7accc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-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.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Eugen.Konkov | 2008-03-28 10:08:02 | Documentation commenting does not work |
Previous Message | Eugen.Konkov | 2008-03-28 09:56:41 | Redundant explicit field name/types description while select from function with return type of record |
From | Date | Subject | |
---|---|---|---|
Next Message | Tino Wildenhain | 2008-03-28 10:17:18 | Re: Surfacing qualifiers |
Previous Message | Simon Riggs | 2008-03-28 09:44:42 | Re: Commitfest patches |