Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
Date
Msg-id 200011021930.OAA29820@candle.pha.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
 


pgsql-hackers by date:

Previous
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Next
From: Peter Eisentraut
Date:
Subject: Why is failure to find file a "NOTICE"?