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 по дате отправления: