Re: [GENERAL] [HACKERS] Inherited constraints and search paths (was

2005-05-30 Thread Bruce Momjian
Added to TODO: * Prevent child tables from altering constraints like CHECK that were inherited from the parent table --- Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Doing anything to res

Re: [GENERAL] [HACKERS] Inherited constraints and search paths (was Re:

2005-05-20 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > If you were going to fix that by adding a column that allows me to tell > the difference between inherited and non-inherited relations, that would > be a very useful piece of info for partition elimination. Inherited and non-inherited constraints you mean?

Re: [GENERAL] [HACKERS] Inherited constraints and search paths

2005-05-20 Thread Simon Riggs
On Fri, 2005-05-20 at 11:51 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Doing anything to restrict dropping of inherited constraints seems like > > wasted effort and potentially annoying anyhow. > > Uh, why? Arguably the constraints are as much part of the parent table >

Re: [GENERAL] [HACKERS] Inherited constraints and search paths (was Re:

2005-05-20 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > Doing anything to restrict dropping of inherited constraints seems like > wasted effort and potentially annoying anyhow. Uh, why? Arguably the constraints are as much part of the parent table definition as the columns themselves. If you had "check (f1 >