pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)

Added utility script pg_dumpaccounts to contrib.

Derived from pg_dumpall it just dumps users and groups.

We can do the same thing with a 5-line change in pg_dumpall. We don't
need an extra copy&pasted program for that.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

I think the issue is that we don't want to risk breaking pg_dumpall in a
minor release.

Comments?

Added utility script pg_dumpaccounts to contrib.

Derived from pg_dumpall it just dumps users and groups.

We can do the same thing with a 5-line change in pg_dumpall. We don't
need an extra copy&pasted program for that.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

I think the issue is that we don't want to risk breaking pg_dumpall in a
minor release.

Comments?

For 7.0.x, let's leave pg_dumpall alone -- it's too important to risk
breakage without extensive beta testing prior to release. An added
contrib utility is not a problem -- in fact, contrib tree changes, being
that they're by nature not a part of the main tree, probably can be
accomodated even when main tree changes can't.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think the issue is that we don't want to risk breaking pg_dumpall in a
minor release.

No we don't, but I agree with Peter that pg_dumpall is the place for
this feature in the long run. A separate contrib script is not going
to get maintained.

What I want to know is why we are adding features at all in a minor
release. Especially 24 or so hours before release, when there is
certainly no time for any testing worthy of the name. Contrib or no
contrib, I think this is a bad idea and a bad precedent.

regards, tom lane

Tom, your feelings on this? Does Lamar's argument change anything?

I agree this is not optimial, and see arguments against its inclusion
even in /contrib.

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think the issue is that we don't want to risk breaking pg_dumpall in a
minor release.

No we don't, but I agree with Peter that pg_dumpall is the place for
this feature in the long run. A separate contrib script is not going
to get maintained.

What I want to know is why we are adding features at all in a minor
release. Especially 24 or so hours before release, when there is
certainly no time for any testing worthy of the name. Contrib or no
contrib, I think this is a bad idea and a bad precedent.

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Well, here in relatively minor form is the First Example of a Great
Bridge Priority (which Tom, Bruce, and Jan have all predicted would
come... ;-)

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?

If it *is* necessary (or at least worthwhile), is it the consensus of
the -hackers community that it go in /contrib?

Thanks,
Ned

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think the issue is that we don't want to risk breaking pg_dumpall in a
minor release.

No we don't, but I agree with Peter that pg_dumpall is the place for
this feature in the long run. A separate contrib script is not going
to get maintained.

What I want to know is why we are adding features at all in a minor
release. Especially 24 or so hours before release, when there is
certainly no time for any testing worthy of the name. Contrib or no
contrib, I think this is a bad idea and a bad precedent.

regards, tom lane

--
----------------------------------------------------
Ned Lilly e: ned@greatbridge.com
Vice President w: www.greatbridge.com
Evangelism / Hacker Relations v: 757.233.5523
Great Bridge, LLC f: 757.233.5555

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?

If it *is* necessary (or at least worthwhile), is it the consensus of
the -hackers community that it go in /contrib?

Since it is a never-before-asked-for new feature appearing in a minor
release, and it is probably going away in 7.1, it is lucky to be getting
into /contrib. :-)

There is a good argument that it shouldn't be in 7.0.3 at all, and we
need the opinion of the hackers group to come to a consensus.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Thu, 2 Nov 2000, Bruce Momjian wrote:

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?

If it *is* necessary (or at least worthwhile), is it the consensus of
the -hackers community that it go in /contrib?

Since it is a never-before-asked-for new feature appearing in a minor
release, and it is probably going away in 7.1, it is lucky to be getting
into /contrib. :-)

There is a good argument that it shouldn't be in 7.0.3 at all, and we
need the opinion of the hackers group to come to a consensus.

I think /contrib is the proper place for it no matter when it shows up.
Whether it's a patch release or major release, it's not like it's an
addition that's changing the course of giant rivers or anything like that.
It's a simple tool that fills a void. Looking at the other stuff that's
already in contrib I don't see what all the hoopla's about.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

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@alert.infoplease.com
Learning Network Reference http://www.infoplease.com
Netsaint Plugin Developer kdebisschop@users.sourceforge.net

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, your feelings on this? Does Lamar's argument change anything?

Not for me. I understand Lamar's concern, but the time to be responding
to it was two weeks ago, not today. 7.0.3 is long overdue already ---
and in fact would be out now, had you not been out of town earlier this
week, no?

I also don't like the fact that a commit change appeared without any
prior discussion or even notice ... not the way to do things for a
patch-release, IMHO.

Basically I want to get 7.0.3 out the door so we can focus our full
attention on getting 7.1 to beta. Last-minute marginal hacks are not
the way to go.

regards, tom lane

Ned Lilly writes:

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.

I only wonder since when the solution to a problem of the nature "I need a
program like X, that does A but not B" is to make a textual copy of X,
remove all the parts that do B, and sell it as a different program.

I added an option for pg_dumpall now to only dump the users and
groups. This whole thing will probably break horribly in semantics once
we implement SQL roles, though.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Ned Lilly <ned@greatbridge.com> writes:

Well, here in relatively minor form is the First Example of a Great
Bridge Priority (which Tom, Bruce, and Jan have all predicted would
come... ;-)

Hmm. I wasn't aware that Jan had done it at Great Bridge's request,
and I am going to make a point of not letting that affect my opinion ;-).

What really got my ire up was that this change was committed several
days *after* core had agreed that 7.0.3 was frozen and ready to go except
for updating the changelog, and that it was committed with no prior
notice or discussion. The fact that GB asked for it doesn't make that
better; if anything it makes it worse. We wouldn't have accepted such
a patch at this late date from an outside contributor, I believe.
Jan should surely have known better than to handle it in this fashion.

Need I remind you, also, that GB has been bugging us for several weeks
to get 7.0.3 released ASAP? Last-minute changes don't further that
goal.

The early returns from pghackers seem to be that people favor just
dropping the script into /contrib and not worrying about how well
tested/documented it is. If that's the consensus then I'll shut up
... but I do *not* like the way this was handled.

regards, tom lane

Ned Lilly <ned@greatbridge.com> writes:

Well, here in relatively minor form is the First Example of a Great
Bridge Priority (which Tom, Bruce, and Jan have all predicted would
come... ;-)

Hmm. I wasn't aware that Jan had done it at Great Bridge's request,
and I am going to make a point of not letting that affect my opinion ;-).

What really got my ire up was that this change was committed several
days *after* core had agreed that 7.0.3 was frozen and ready to go except
for updating the changelog, and that it was committed with no prior
notice or discussion. The fact that GB asked for it doesn't make that
better; if anything it makes it worse. We wouldn't have accepted such
a patch at this late date from an outside contributor, I believe.
Jan should surely have known better than to handle it in this fashion.

Need I remind you, also, that GB has been bugging us for several weeks
to get 7.0.3 released ASAP? Last-minute changes don't further that
goal.

The early returns from pghackers seem to be that people favor just
dropping the script into /contrib and not worrying about how well
tested/documented it is. If that's the consensus then I'll shut up
... but I do *not* like the way this was handled.

I totally agree with Tom on all his points. If people were worried we
would not be objective now that we are employed by GB, they can rest
easy.

Also, seems like it is hidden enough in /contrib for it to stay. While
I would not have added it myself, I do not feel strongly enough to
remove Jan's commit. However, I am not going to mention it in the 7.0.3
release notes.

I want it removed from 7.1 /contrib. I will do that now myself.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I want it removed from 7.1 /contrib. I will do that now myself.

Looks like Peter has already eliminated the need for it for 7.1 ;-).
What remains to discuss is just whether we want it as a contrib item
in 7.0.3.

As several people mentioned, it's harmless enough in contrib. I'm
mainly objecting on principle --- this should've been done with more
attention to protocol.

regards, tom lane

Tom Lane wrote:

What really got my ire up was that this change was committed several
days *after* core had agreed that 7.0.3 was frozen and ready to go except
for updating the changelog, and that it was committed with no prior

Now that I've seen the back story, I must agree.

The early returns from pghackers seem to be that people favor just
dropping the script into /contrib and not worrying about how well
tested/documented it is. If that's the consensus then I'll shut up
... but I do *not* like the way this was handled.

Bruce I believe has made a good call -- it goes in contrib for now, and
gets yanked for 7.1, which _might_ have the same functionality as a
pg_dump/pg_dumpall option (which will then get wrung out on beta
testing).

But I agree -- I'm not thrilled with the method.

The functionality itself sounds nice -- but I know we need a solid 7.0.3
out. New functionality belongs in 7.1. Until beta -- and then a freeze
there.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I want it removed from 7.1 /contrib. I will do that now myself.

Looks like Peter has already eliminated the need for it for 7.1 ;-).
What remains to discuss is just whether we want it as a contrib item
in 7.0.3.

As several people mentioned, it's harmless enough in contrib. I'm
mainly objecting on principle --- this should've been done with more
attention to protocol.

Totally agree, and I made that point clear to GB staff. Hopefully Jan
will read this when he gets online and know about it too. I will phone
him now to update him on the issues.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Thu, 2 Nov 2000, Ned Lilly wrote:

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).

Okay, because of this paragraph, and this one only, I will agree with Tom
(and I believe Bruce) that this should be removed. If, as Peter states,
this could be put into pg_dump in 5 lines, and as you say, it is a
temporary hack, then more appropriate would be to put a link off of the
web site and *not* put it into the source distribution ...

I like what it does, since I can relate to the need to dump user/group
info seperate from everything else, but if a permanent fix is as doable as
Peter states, putting a temporary one, especially into a minor release,
makes little to no sense ...

My vote is to please remove it from the source tree ...

If it *is* necessary (or at least worthwhile), is it the consensus of
the -hackers community that it go in /contrib?

Altho this is going to force me to agree with Tom concerning Karel's
patch, it should not be added to the 7.0.x branch *at all* ... 7.0.x is a
*patch* release, new features are for 7.1 and 7.1 only ...

On Thu, 2 Nov 2000, Tom Lane wrote:

Ned Lilly <ned@greatbridge.com> writes:

Well, here in relatively minor form is the First Example of a Great
Bridge Priority (which Tom, Bruce, and Jan have all predicted would
come... ;-)

Hmm. I wasn't aware that Jan had done it at Great Bridge's request,
and I am going to make a point of not letting that affect my opinion ;-).

What really got my ire up was that this change was committed several
days *after* core had agreed that 7.0.3 was frozen and ready to go except
for updating the changelog, and that it was committed with no prior
notice or discussion. The fact that GB asked for it doesn't make that
better; if anything it makes it worse. We wouldn't have accepted such
a patch at this late date from an outside contributor, I believe.
Jan should surely have known better than to handle it in this fashion.

Need I remind you, also, that GB has been bugging us for several weeks
to get 7.0.3 released ASAP? Last-minute changes don't further that
goal.

The early returns from pghackers seem to be that people favor just
dropping the script into /contrib and not worrying about how well
tested/documented it is. If that's the consensus then I'll shut up
... but I do *not* like the way this was handled.

I will back up Tom on this and vote against even putting it into /contrib
... the only reason we delayed the release as we did was so that Bruce
could finish up the release docs, not to give "just one more patch" time
to get into the tree.

Tom, apologies ... the Karel issue is the same thing, and I was in err for
even suggesting we put *that* into contrib.

On Thu, 2 Nov 2000, Bruce Momjian wrote:

Ned Lilly <ned@greatbridge.com> writes:

Well, here in relatively minor form is the First Example of a Great
Bridge Priority (which Tom, Bruce, and Jan have all predicted would
come... ;-)

Hmm. I wasn't aware that Jan had done it at Great Bridge's request,
and I am going to make a point of not letting that affect my opinion ;-).

What really got my ire up was that this change was committed several
days *after* core had agreed that 7.0.3 was frozen and ready to go except
for updating the changelog, and that it was committed with no prior
notice or discussion. The fact that GB asked for it doesn't make that
better; if anything it makes it worse. We wouldn't have accepted such
a patch at this late date from an outside contributor, I believe.
Jan should surely have known better than to handle it in this fashion.

Need I remind you, also, that GB has been bugging us for several weeks
to get 7.0.3 released ASAP? Last-minute changes don't further that
goal.

The early returns from pghackers seem to be that people favor just
dropping the script into /contrib and not worrying about how well
tested/documented it is. If that's the consensus then I'll shut up
... but I do *not* like the way this was handled.

I totally agree with Tom on all his points. If people were worried we
would not be objective now that we are employed by GB, they can rest
easy.

Also, seems like it is hidden enough in /contrib for it to stay. While
I would not have added it myself, I do not feel strongly enough to
remove Jan's commit. However, I am not going to mention it in the 7.0.3
release notes.

I do feel strongly about this ... 7.0.3 was considered in a release state
*before* it was committed, pending your docs changes ... personally, if we
leave this in contrib, my vote is to hold off the release a suitable
amount of time for testing purposes ... Jan has added a new feature that
nobody had any pre-warning about, not even other developers in the same
company as he is in ... not a good precedent :(