Re: Open 7.3 items

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Ron Snyder <snyder(at)roguewave(dot)com>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Open 7.3 items
Date: 2002-08-13 01:28:41
Message-ID: 200208122128.41030.lamar.owen@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2002-08-13 01:34:48 Re: OOP real life example (was Re: Why is MySQL more
Previous Message Tatsuo Ishii 2002-08-13 01:11:05 Re: regression test failure