Re: pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Дмитрий Воронин <carriingfate92(at)yandex(dot)ru>
Cc: Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump
Date: 2015-10-29 14:51:20
Message-ID: 28942.1446130280@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?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. 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

In response to

  • Re: pg_dump at 2015-10-29 14:05:02 from Дмитрий Воронин

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2015-10-29 14:56:54 Re: Personal note: changing employers
Previous Message Oleksii Kliukin 2015-10-29 14:29:43 Re: [ADMIN] Replication slots and isolation levels