Thread: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Peter Eisentraut
Date:
> 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/
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (MakefileREADME pg_dumpaccounts.sh)
From
Lamar Owen
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Tom Lane
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Ned Lilly
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Vince Vielhaber
Date:
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.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Karl DeBisschop
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Tom Lane
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Peter Eisentraut
Date:
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/
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Tom Lane
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Tom Lane
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Lamar Owen
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
The Hermit Hacker
Date:
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.
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
The Hermit Hacker
Date:
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 ...
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
The Hermit Hacker
Date:
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 :(
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Tom Lane
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> > 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Vince Vielhaber
Date:
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.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Vince Vielhaber
Date:
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.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> > > 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Larry Rosenman
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
The Hermit Hacker
Date:
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 :)
> 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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
"Ross J. Reedstrom"
Date:
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.
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Peter Eisentraut
Date:
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/
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Tom Lane
Date:
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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
The Hermit Hacker
Date:
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" ...
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Bruce Momjian
Date:
> 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, Pennsylvania19026
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
From
Karl DeBisschop
Date:
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 administrativeease 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'dbe just as happy if there were a link to the file on the download page. Or if it was placed in an "interim" directoryor something like that. I just want it to be available. I would prefer if it could be done in a way that's consistentwith 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
Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh))
From
Jan Wieck
Date:
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 realsolution, 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 #