Re: [HACKERS] Inherited constraints and search paths (was Re:
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 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. Best Regards, Simon Riggs ---(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
Re: [HACKERS] Inherited constraints and search paths (was Re: [GENERAL] Preserving data after updates)
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 partition (do you mean schema?), although that arrangement was considered and rejected for other reasons during data base design. I should clarify: the version of the pg_dump bug that still exists in HEAD is triggered by putting the child table in a different schema than the parent. 7.3 has different behavior --- offhand I think that in 7.3 the problem can occur if the child table is created while search_path is set differently than it was when the parent was created. (Of course, across multiple pg_dump and reload cycles this may boil down to the same thing. But there are more ways to burn yourself given the 7.3 implementation.) regards, tom lane ---(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
Re: [HACKERS] Inherited constraints and search paths (was Re: [GENERAL]
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? 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 6: Have you searched our list archives? http://archives.postgresql.org
