Simon Riggs wrote:
On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote:
Berend Tober <btober@xxxxxxxxxxxxxxxx> 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 prevent people from creating child tables in
different schemas. Or at least advise against it.
Doing anything to restrict dropping of inherited constraints seems like
wasted effort and potentially annoying anyhow.
My partitioning efforts will eventually distinguish between inherited
and non-inherited constraints, since the former are fairly useless for
partition elimination. So I can't see a reason to care whether they are
there or not, if the user knows better.
The case in question was not one of the child table being in a different
partition (do you mean schema?), although that arrangement was
considered and rejected for other reasons during data base design. In
this implementation, a function called for a table constraint was in a
different schema. The function so called was defined in the public
scheme because it is a generic function that can be used by different
applications, and some tables are relevant only to specific applications
and so have there own, application-specific schema -- but they still can
make use of shared definitions, i.e., this particular function, which
are defined in the public schema.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
