Re: [HACKERS] Inherited constraints and search paths (was Re: Preserving data after updates)

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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