Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
От | Karl DeBisschop |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh) |
Дата | |
Msg-id | 3A01CF6F.A8182417@alert.infoplease.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 shameto 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 functionalityinto the release. But I would like it if this functionality could somehow become part of PostgreSQL as soonas is feasible. Just my $0.02 worth. -- Karl DeBisschop kdebisschop@alert.infoplease.com Learning Network Reference http://www.infoplease.com Netsaint Plugin Developer kdebisschop@users.sourceforge.net
В списке pgsql-hackers по дате отправления: