| 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: | Whole Thread | Raw Message | 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 |