From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | btober(at)computer(dot)org |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgreSQL(dot)org, pgsql-general(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Inherited constraints and search paths (was Re: Preserving data after updates) |
Date: | 2005-05-20 13:55:37 |
Message-ID: | 24344.1116597337@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Berend Tober <btober(at)seaworthysys(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2005-05-20 14:04:08 | Re: numeric precision when raising one numeric to another. |
Previous Message | Scott Marlowe | 2005-05-20 13:49:44 | Re: Postgres in government |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-05-20 14:17:45 | Re: patches for items from TODO list |
Previous Message | Dave Cramer | 2005-05-20 13:43:50 | Re: 8.02 rpm error |