Re: pg_dump

On Thu, Oct 29, 2015 at 7:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?koi8-r?B?5M3J1NLJyiD3z9LPzsnO?= <carriingfate92(at)yandex(dot)ru> writes:
>>> šIt's a problem. See this recent discussion:
>>> šhttp://www.postgresql.org/message-id/flat/20150710115735(dot)GH26521(at)alap3(dot)anarazel(dot)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