Re: Inherited constraints and search paths (was Re: [GENERAL] Preserving data after updates)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Inherited constraints and search paths (was Re: [GENERAL] Preserving data after updates) |
| Дата | |
| Msg-id | 24344.1116597337@sss.pgh.pa.us обсуждение |
| Ответ на | Inherited constraints and search paths (was Re: [GENERAL] Preserving data after updates) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Berend Tober <btober@seaworthysys.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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера