Re: Open 7.3 items - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: Open 7.3 items
Date
Msg-id 200208122128.41030.lamar.owen@wgcr.org
Whole thread Raw
In response to Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Open 7.3 items  (Karl DeBisschop <kdebisschop@alert.infoplease.com>)
List pgsql-hackers
On Saturday 10 August 2002 10:41 pm, Bruce Momjian wrote:
> Let me give a little history.  The secondary password file was created
> at a time when we didn't encrypt with random salt over the wire, and we
> had people who wanted to share their /etc/passwd file with PostgreSQL.
[snip]

> So, based on the voting, I think dbname.username is an agreed-upon
> feature addition for 7.3.  I will work on a final patch with
> documentation and post it to the patches list for more comment.

I can live with this, if the documentation is prominently referred to in the 
changelog.

As to the feature itself, I believe Bruce's proposed solution is the best, and 
believed that from the beginning -- I just wanted to deal with the 'fair 
warning' issue alone.

As to fair warning:  watch for the next RPM release.  Fair Warning is being 
given that upgrades within the RPM context will not be supported in any form 
for the final release of PostgreSQL 7.3. 

I had a 'd'oh' moment (and I don't watch the Simpsons....) when I realized 
that I could quite easily prevent anyone from even attempting an RPM upgrade, 
unless that take matters into their own grubby little hands with special 
switches to the rpm command line. 

It will not be yanked this next set, but the following set will be 
unupgradable.  Sorry, but the packaged kludge isn't reliable enough for the 
state of PostgreSQL reliability, and I don't want the RPMset's shortcomings 
(due to the whole RPM mechanism forcing the issue) causing bad blood towards 
PostgreSQL in general. The Debian packages don't have much of the limitations 
and restrictions I have to deal with, and until a good upgrade utility is 
available I'm just going to have to do this.

I have been so swamped with Fortran work for work that I've not even looked at 
the python code Hannu so kindly sent me, nor have I played any more with 
pg_fsck.  Groundwave propagation modeling in Fortran has been more 
important...

Likewise, my focus as RPM maintainer is changing with this next release.  
Since the distributions, such as Red Hat, are doing a great job keeping up to 
date, I'm going to not bother much with building RPMs that are, frankly, 
redundant at this point.  Three years ago it wasn't this nice.  Trond has 
done a good job on the Red Hat bleeding edge front, Reinhard Max has done 
similarly for SuSE.  There are PLD, Connectiva, TurboLinux, Caldera, and 
Mandrake maintainers as well -- and they seem to be doing fine.

I'm going to now go to the lagging plane -- building newer PostgreSQL for 
older Red Hat (and maybe others, if I can get enough hard drives available).  
The source RPM will still be useful to the newer distribution's maintainers 
-- but the requests I see more of on the lists is newer PostgreSQL on older 
linux.  So I'm going to try to rise to that occassion, and take this 
opportunity to apologize for not seeing it sooner.

I welcome comments on this change of focus.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: regression test failure
Next
From: Curt Sampson
Date:
Subject: Re: OOP real life example (was Re: Why is MySQL more