Re: Further cleanup of pg_dump/pg_restore item selection code

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Further cleanup of pg_dump/pg_restore item selection code
Дата
Msg-id CAKFQuwaOXgTj+C1cNDsb9qTaNGZBS0xb9fXngOjgikNG4F=wqw@mail.gmail.com
обсуждение исходный текст
Ответ на Further cleanup of pg_dump/pg_restore item selection code  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wednesday, January 24, 2018, Tom Lane <tgl@sss.pgh.pa.us> wrote:

This does not go all the way towards making pg_restore's item selection
switches dump subsidiary objects the same as pg_dump would, because
pg_restore doesn't really have enough info to deal with indexes and
table constraints the way pg_dump does.  Perhaps we could intuit the
parent table by examining object dependencies, but that would be a
bunch of new logic that seems like fit material for a different patch.
In the meantime I just added a disclaimer to pg_restore.sgml explaining
this.

Unless we really wanted to keep prior-version compatibility it would seem more reliable to have pg_dump generate a new TOC entry type describing these dependencies and have pg_restore read and interpret them during selective restore mode.  Basically a cross-referencing "if you restore A also restore B". Where A can only be tables and B indexes and constraints (if we can get away with it being that limited initially).

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: CREATE ROUTINE MAPPING
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Further cleanup of pg_dump/pg_restore item selection code