Hi Alex,

On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <badalex@gmail.com> wrote:

> On Thu, Mar 27, 2008 at 5:14 AM, NikhilS <nikkhils@gmail.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

NikhilS escribió:

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

Argh, you are right. We don't have this on the archives anywhere :-(
Probably it got stuck on Maia ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi Alvaro

On Fri, Mar 28, 2008 at 6:05 PM, Alvaro Herrera <alvherre@commandprompt.com>
wrote:

> NikhilS escribió:
>
> > 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.
>
> Oh, BTW, I have not added this patch to any Commitfest page on the wiki,
> since it has obvious things that need more work. If you do work on
> them, please post the improved patch later and add it to the
> corresponding Commitfest, as appropriate.
>

I submitted the combined latest patch to the patches list yesterday. How can
I add it to the commitfest (presumably to the May one?)? Please let me know..


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