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 :(

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

OK, we have votes from Lamar, Ned, Jan, and someone else to keep it in
/contrib, votes from Marc and Tom to remove it completely.

Other votes?

It will not be mentioned in the release notes.

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

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 :(

The fact that we are in the same company is pretty meaningless, as you
have seen.

However, we do have two core developers opposed, one for it, and three
users for it. I am not voting because I can see both points.

I think we need more votes or a general core vote. I am branding 7.0.3
now, so we have a little time for more votes, perhaps from other core
members.

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

The Hermit Hacker <scrappy@hub.org> writes:

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

Er, since when do we do pre-release testing of contrib stuff? I'm
generally in agreement that this wasn't a good idea, but I don't see a
reason to hold off the release to test it. Let's wait till tomorrow to
see if we get more votes, and then it's either in or out.

regards, tom lane

On Thu, 2 Nov 2000, Bruce Momjian wrote:

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

OK, we have votes from Lamar, Ned, Jan, and someone else to keep it in
/contrib, votes from Marc and Tom to remove it completely.

Other votes?

It will not be mentioned in the release notes.

So now I'm only a "someone else"? Wait till you see your next link!

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

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

OK, we have votes from Lamar, Ned, Jan, and someone else to keep it in
/contrib, votes from Marc and Tom to remove it completely.

Other votes?

It will not be mentioned in the release notes.

So now I'm only a "someone else"? Wait till you see your next link!

No, actually, I forgot you had voted, which may be worse than forgetting
your name. Vince is another vote to keep it in /contrib.

-- 
  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, The Hermit Hacker wrote:

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 :(

What am I missing? We're talking about contrib. Most things you find
in contrib directories don't even work and you're worried about a testing
phase? Most folks don't even look in contrib directories unless they're
specifically looking for something.

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

On Thu, 2 Nov 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

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

Er, since when do we do pre-release testing of contrib stuff? I'm
generally in agreement that this wasn't a good idea, but I don't see a
reason to hold off the release to test it. Let's wait till tomorrow to
see if we get more votes, and then it's either in or out.

Sorry, should have added a smiley at the end of that :)

While I see both sides, this looks like an *INTERNAL* *CORE* debate.

From a USER perspective the functionality is useful. From a Software
Development perspective, the timing stinks.

I'd leave it in /contrib, and make damn sure we get the right
functionality into the 7.1 release.

LER

* Vince Vielhaber <vev@michvhf.com> [001102 19:18]:

On Thu, 2 Nov 2000, The Hermit Hacker wrote:

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 :(

What am I missing? We're talking about contrib. Most things you find
in contrib directories don't even work and you're worried about a testing
phase? Most folks don't even look in contrib directories unless they're
specifically looking for something.

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

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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 :(

To me the whole point of the contrib directory is as a place for
stuff that is not officially part of the release, but that somebody
might find interesting or even useful. If we start enforcing
elaborate rules about what can go in there, then we will need
another place to put stuff that doesn't fit those rules but might
nonetheless be interesting or even useful. Where does it end?

This is a vote for leaving the addition in place. It is also a
vote for clarifying that contrib is, specifically, the place to
to put potentially useful things that have not been officially
qualified. The distinction is made to relieve pressure to add
insufficiently-considered features to the release proper, a
function contrib can serve only if it is allowed to.

Nathan Myers
ncm@zembu.com

I agree with leaving it be in contrib. The lesson has been learned,
and contrib has certainly gone out in _much_ worse shape, with code that
wouldn't even compile.

Ross
--
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers
and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.

Bruce Momjian writes:

OK, we have votes from Lamar, Ned, Jan, and someone else to keep it in
/contrib, votes from Marc and Tom to remove it completely.

Other votes?

What part of "no new features in bug-fix releases" is giving people
trouble?

If Great Bridge wants this in their platinum certified re-release, nothing
is stopping them. If Great Bridge "bugs" people to release ASAP, why
don't they release it themselves?

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

Bruce Momjian writes:

OK, we have votes from Lamar, Ned, Jan, and someone else to keep it in
/contrib, votes from Marc and Tom to remove it completely.

Other votes?

What part of "no new features in bug-fix releases" is giving people
trouble?

If Great Bridge wants this in their platinum certified re-release, nothing
is stopping them. If Great Bridge "bugs" people to release ASAP, why
don't they release it themselves?

Certainly none of this should be based on Great Bridge and their
supplying of the patch, though their contacting Jan directly and him
making the change with no discussion was a major mistake. Also, having
him install it as a new command in /bin/pg_dump/ was a major mistake
too.

I have talked to GB and they understand their error. Some people want
to yank it out of /contrib too because of this error, and I can
understand that reaction.

It just re-illustrates that Great Bridge has some things to learn in
working with the open-source community.

The larger questions is whether we allow feature additions to /contrib
in minor releases. I think we do. In fact, I think I have even
installed new 3rd party stuff like pgaccess in minor releases. In fact,
6.5.3 has

Updated version of pgaccess 0.98

and I am not sure if that was a bug fix or feature change to pgaccess,
but the conclusion was that it is a 3rd party thing and the person who
wrote it is responsible for making sure it works. I think the same can
be said of /contrib.

Comments?

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

Peter Eisentraut <peter_e@gmx.net> writes:

What part of "no new features in bug-fix releases" is giving people
trouble?

Interesting observation here: the key developers seem to be much more
exercised about this than the rest of the community. Counting core
members and Peter we have three "no" and one "yes", whereas as best
I recall the votes from the rest of pghackers are about 6 to 1 in
favor.

Make of that what you will --- but I'm going to yield the point,
since the non-core sentiment seems to be very clear.

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

What part of "no new features in bug-fix releases" is giving people
trouble?

Interesting observation here: the key developers seem to be much more
exercised about this than the rest of the community. Counting core
members and Peter we have three "no" and one "yes", whereas as best
I recall the votes from the rest of pghackers are about 6 to 1 in
favor.

Make of that what you will --- but I'm going to yield the point,
since the non-core sentiment seems to be very clear.

I think the core/active group is more negative because of the way this
was done, with GB calling Jan, and Jan jamming it in with no discussion.

Jan originally had it in /bin/pg_dump as a new command and a new manual
page. You can image the firestore that would have caused. I called him
right away and got it into /contrib.

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

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

What part of "no new features in bug-fix releases" is giving people
trouble?

Interesting observation here: the key developers seem to be much more
exercised about this than the rest of the community. Counting core
members and Peter we have three "no" and one "yes", whereas as best
I recall the votes from the rest of pghackers are about 6 to 1 in
favor.

Make of that what you will --- but I'm going to yield the point,
since the non-core sentiment seems to be very clear.

ISTM that devlopers are correctly concerned about policy. And ISTM that users place a slightly higher premium on administrative ease than they do on consistency. Nothing really wrong with that either.

My guess is that users would be very happy to yield on placing the script in /contrib if some alternate were proposed. I'd be just as happy if there were a link to the file on the download page. Or if it was placed in an "interim" directory or something like that. I just want it to be available. I would prefer if it could be done in a way that's consistent with the project policy, but that consistency is just slightly less important to me than short-term usability.

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

Peter Eisentraut <peter_e@gmx.net> writes:

What part of "no new features in bug-fix releases" is giving people
trouble?

Interesting observation here: the key developers seem to be much more
exercised about this than the rest of the community. Counting core
members and Peter we have three "no" and one "yes", whereas as best
I recall the votes from the rest of pghackers are about 6 to 1 in
favor.

Make of that what you will --- but I'm going to yield the point,
since the non-core sentiment seems to be very clear.

One final analysis of this. If Jan had come to the list and explained
the problem, and suggested adding something to /contrib for 7.0.3, I
think most people would have said OK.

My guess is that many of the negative votes are based on the way this
was handled. I know I think about how this was handled and get upset
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

On Fri, 3 Nov 2000, Bruce Momjian wrote:

I have talked to GB and they understand their error.

Until the next time? This isn't the first time you've "talked to
them" ...

Bruce Momjian wrote:

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.

Need to apologize for all the trouble caused.

My approach was to meet the documentations deadline of Mark
Cotton, while making it as easy, safe and 7.0.3 vs. 7.1
compatible. I know that it'll not stand the test of time.
Finally (with roles) we need to develop a real solution, but
this was IMHO better than void (what we had before).

Due to my current crazy situation, there was no time for a
discussion, so I decided just not to touch any existing code
(not a single byte) and put it in as a separate script, MEANT
to be removed subsequently again.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #