Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)

From: Karl DeBisschop <kdebisschop(at)alert(dot)infoplease(dot)com>
To:
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
Date: 2000-11-02 20:32:47
Message-ID: 3A01CF6F.A8182417@alert.infoplease.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Ned Lilly wrote:

> Our feeling is that DBAs will want to have the ability to backup user
> and group info, which you currently can't do with pg_dump. You *can* do
> it with pg_dumpall - but only if you dump every database you've got at
> the same time. Picture a professional environment where you might have
> many different databases running 24/7 - and doing a pg_dumpall across
> all of them at once just isn't practical. Most DBAs would prefer to
> stagger their regular backups in such an environment, one database at a
> time. Indeed, those backups are often on fixed schedules, at different
> times, for real business reasons. And if you do that, you can't backup
> the aforementioned system catalogs.
>
> That's what this pg_dumpaccounts is designed to do. As you've seen,
> it's very simple - it does the same COPY stuff that pg_dumpall does
> before calling pg_dump, just without the pg_dump. It's an inelegant
> solution, and shame on us for not catching the problem sooner. But it
> *is* a problem, albeit perhaps one that current PostgreSQL users haven't
> run into yet. We're concerned that people might have a false sense of
> security with pg_dump - that they might think if they backup one
> database, they're able to do a full restore. They're not. And like I
> said, there are situations when pg_dumpall isn't the appropriate solution.
>
> We recognize this is a temporary hack - and fully expect it to go away
> in 7.1 We actually think that the final solution might be more
> appropriate in pg_dump itself than pg_dumpall, but that's obviously a
> much more breakable proposition (hence the separate utility).
>
> I understand everyone's hesitation about adding a new utility this late
> in the process - and we're happy to be overruled on that (even if it's a
> discrete piece of code that wouldn't affect anything else...) I'm not
> wild about putting it in /contrib, but if that's what everyone wants to
> do, ok.
>
> Have we adequately explained the need for this? Or do people think it's
> not necessary?

As a user, I think it is necessary. In fact, I was planning to write a version of such a utility myself. It would be a shame to have to duplicate someone else's work because policy was more important than usability.

Putting a short-lived utility in contrib seems fine to me, FWIW. I would certainly prefer that to putting less tested functionality into the release. But I would like it if this functionality could somehow become part of PostgreSQL as soon as is feasible.

Just my $0.02 worth.

--
Karl DeBisschop kdebisschop(at)alert(dot)infoplease(dot)com
Learning Network Reference http://www.infoplease.com
Netsaint Plugin Developer kdebisschop(at)users(dot)sourceforge(dot)net

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2000-11-02 20:42:43 Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
Previous Message Vince Vielhaber 2000-11-02 20:30:17 Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-11-02 20:32:58 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Vince Vielhaber 2000-11-02 20:30:17 Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)