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

Simon Riggs wrote:

>On Thu, 2005-05-19 at 23:27 -0400, Tom Lane wrote:
>
>
>>Berend Tober <btober@seaworthysys.com> 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.