Re: Problem identifying constraints which should not be inherited

On Fri, Mar 28, 2008 at 4:07 AM, NikhilS <nikkhils(at)gmail(dot)com> wrote:
> Hi Alex,
>
>
> On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> > 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 that should say first 3 items...

>
> 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 :)
>

Yeah I was planning on taking the enums out. Or at least the one i
did in pg_constraint.h.... Like I said it was a WIP :) The syscache
stuff mainly for ease of use but can be taken out easily enough if
anyone objects. (I added unique index on conrelid, constrname and
SearchSysCache(CONSTRNAME...) for the curious who did not look at the
patch).

Ill take out the enums and see about getting a real fix for
create table (x int check constraint ...) inherits ((some table that
has an x int check constraint)

expect v2 sometime later today....

> 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.
>

That would be great!

> 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