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
Berend Tober <[EMAIL PROTECTED]> writes:
> However, when I do a select from a view, which itself does a select from
> a parent table, the query result does include the child table rows,
> i.e., the SQL_INHERITANCE setting is ignored in this situation. Should
> the SQL_INHERITANCE setting still
Tom Lane wrote:
...
I just ran into another inheritance-related oddness. Well maybe it is
not really an oddness -- you tell me.
The problem stems from the fact that I did not originally plan on using
inhertiance and so did not include the ONLY keyword in the FROM clause
of queries coded into my
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?
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 >
On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote:
> Berend Tober <[EMAIL PROTECTED]> writes:
> > Now what, oh most wise one?
>
> OK, now I finally get the point: you are creating child tables in
> different schemas than their parents live in.
...
> Comments anyone?
Best thing to do is to pre
