On Thu, Oct 29, 2015 at 7:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > =?koi8-r?B?5M3J1NLJyiD3z9LPzsnO?= <carriingfat...@yandex.ru> writes: >>> šIt's a problem. See this recent discussion: >>> šhttp://www.postgresql.org/message-id/flat/20150710115735.gh26...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers