Skip site navigation (1) Skip section navigation (2)

Re: Upgrading rant.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Upgrading rant.
Date: 2003-01-03 00:26:06
Message-ID: 5466.1041553566@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8.  It 
> was very bad.  It simply would not build -- I guess it's the gcc 3
> stuff.

If you don't know *exactly* why it doesn't build, I don't think you
should be blaming us for it.  (FWIW, I just tried to build 7.1 branch
on RHL 8.0 --- the main problem seems to be that 7.1's configure isn't
expecting multiline output from "gcc --version", and it produces a
PG_VERSION_STR definition that's missing a trailing quote.  There are
some other issues, none that look very difficult to fix, all indicative
of incompatible changes in either gcc or system include files.)

> THIS DOESN'T HAPPEN WITH MySQL.

Oh?  Do they have a crystal ball that lets them predict incompatible
future platform changes?

(I'm not very sure I believe your assertion above, anyway.  We are
painfully aware of our own compatibility issues, but I wonder how many
people on this list pay close enough attention to MySQL to know what
their version-to-version compatibility track record *really* is.)

> I thought the last time through would be the _last_ time through --
> but I also thought I'd be able to build older PostgreSQL packages for
> newer dists, which would prevent much of this problem.

You could do so if you were willing to track the platform changes.
7.1 isn't hopelessly broken for RHL 8.0, but it's definitely suffering
bit rot.  Someone would have to expend effort on updating obsolete
branches, if we wanted them to keep working in the face of incompatible
platform changes.

> And I'd love to see someone who has the time to do so (not me) grab
> this bull by the horns and make it happen.

Well, this is exactly the issue: someone would have to put substantial
amounts of time into update mechanisms and/or maintenance of obsolete
versions, as opposed to features, performance improvements, or bug
fixes.

Personally, I feel that if we weren't working as hard as we could on
features/performance/bugfixes, the upgrade issue would be moot because
there wouldn't *be* any reason to upgrade.  So I'm not planning to
redirect my priorities.  But this is an open source project and every
developer gets to set their own priorities.  If you can persuade someone
to put their time into that, go for it.

> And I _know_ some are just going to fingerpoint and blame Red Hat.  Any such 
> replies I will rather quickly redirect to /dev/null, as it isn't Red Hat's 
> fault we can't do a sane upgrade.

I think you're wasting your time trying to hold us to a higher standard
of backwards-compatibility than is maintained by the OSes and tools we
must sit on top of.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-01-03 00:33:43
Subject: Re: PostgreSQL Password Cracker
Previous:From: Bruce MomjianDate: 2003-01-02 23:52:27
Subject: Re: PostgreSQL Password Cracker

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group