=?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. Those are the responsibility of pg_dumpall. I'd be the first to agree that maybe this wasn't the best design, but at least it's consistent. If we're going to change things, we need to start by deciding where we're going to re-draw the line, and figuring out what sort of impact that will have in terms of compatibility considerations and users' backup/restore procedures. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers