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 >
Simon Riggs wrote:
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?
Berend Tober <[EMAIL PROTECTED]> writes:
>> On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote:
>>> OK, now I finally get the point: you are creating child tables in
>>> different schemas than their parents live in.
>>
> The case in question was not one of the child table being in a different
>
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
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. This creates a problem
because reverse-listing of the constraints varies depending on what
the search path is.
An
