Re: pg_dump - Mailing list pgsql-hackers

From David Fetter
Subject Re: pg_dump
Date
Msg-id 20151029151025.GC401@fetter.org
Whole thread Raw
In response to Re: pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 29, 2015 at 10:51:20AM -0400, Tom Lane 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.  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.

In this vein, I'd like humbly to suggest that we draw the line in a
way that finishes the already accomplished work of excluding
pg_dumpall entirely.  We should probably leave a pg_dumpall-compatible
wrapper for pg_dump for a few versions, but not if doing so cramps
development.

What pg_dumpall now still does that pg_dump doesn't is, as far as I
know:

- Whole-instance dumping (its original purpose, as far as I can tell)
- Auth (roles/secrets)
- Tablespaces

I believe that a relatively short patch to pg_dump would allow us to
make better versions of at least the first two.  By better, I mean,

- Not require that a whole-instance dump be in a single file, and
- Be able to dump only the auth stuff relevant to the specified DB objects.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Personal note: changing employers
Next
From: Дмитрий Воронин
Date:
Subject: Re: pg_dump