Re: pg_dump

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: pg_dump
Дата
Msg-id CAMkU=1zfcGu0hhVv9TziW-mj6uzMqzKk0cAa=qXN4mqJr4vUQw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Oct 29, 2015 at 7:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Дмитрий Воронин <carriingfate92@yandex.ru> writes:
>>> šIt's a problem. See this recent discussion:
>>> šhttp://www.postgresql.org/message-id/flat/20150710115735.GH26521@alap3.anarazel.de
>
>> Postgresmen, we have a SQL function "current_database", which can be called by statement "SELECT CURRENT_CATALOG".
>
>> If we will use CURRENT_CATALOG keyword, we can update syntax of COMMENT statement:
>
>> COMMENT ON DATABASE CURRENT_CATALOG IS 'comment';
>
>> And pg_dump will create this line for database. What are you think about this idea?
>
> We don't need hasty patches.  What we need is a re-think of the division
> of labor between pg_dump and pg_dumpall.  Up to now, pg_dump has only been
> charged with dumping/restoring the data "inside" an individual database,
> not with handling any database-level properties.

I don't understand this comment.  The whole point of the thread is
that pg_dump (with -C or -Fc) is already dumping this database-level
information, but in a way that doesn't reload if the database name has
changed.  The info is already there, and at least in the case of
COMMENT it has been for a long time.

Cheers,

Jeff



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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: pg_dump
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Freeze avoidance of very large table.