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

Hi,
On Sat, May 10, 2008 at 6:11 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:

> On Fri, May 9, 2008 at 5:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > "Alex Hunsaker" <badalex(at)gmail(dot)com> writes:
> >> [ patch to change inherited-check-constraint behavior ]
> >
> > Applied after rather heavy editorializations. You didn't do very well on
> > getting it to work in multiple-inheritance scenarios, such as
> >
> > create table p (f1 int check (f1>0));
> > create table c1 (f2 int) inherits (p);
> > create table c2 (f3 int) inherits (p);
> > create table cc () inherits (c1,c2);
> >
> > Here the same constraint is multiply inherited. The base case as above
> > worked okay, but adding the constraint to an existing inheritance tree
> > via ALTER TABLE, not so much.
>
> Ouch. Ok Ill (obviously) review what you committed so I can do a lot
> better next time.
> Thanks for muddling through it!
>

Ouchie indeed!

> I'm not sure if we ought to try to back-patch that --- it'd be a
> behavioral change with non-obvious implications. In the back branches,
> ADD CHECK followed by DROP CONSTRAINT will end up not deleting the
> child-table constraints, which is probably a bug but I wouldn't be
> surprised if applications were depending on the behavior.

Given the lack complaints it does not seem worth a back patch IMHO.
>
Yeah, same IMHO. I do hope we have covered things properly for inherited
check constraints by now. One minor thing that myself and Alex discussed was
the usage of "child tables" in tablecmds.c, especially in error messages.
Again English is not my native language, but shouldn't that be worded as
"children tables"? Admittedly even this does not sound any better than
"child tables" though :). It is nit-picking really, but I can submit a
cleanup patch to reword this if the list thinks so..

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