Re: Can we revisit the thought of PostgreSQL 7.2.4?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Justin Clift <justin(at)postgresql(dot)org>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can we revisit the thought of PostgreSQL 7.2.4?
Date: 2003-01-18 16:13:26
Message-ID: 24531.1042906406@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> ... Why? If a user doesn't need the features of 7.x.x, and the codebase is
> working well for him/her, why should said user/DBA feel compelled to go
> through who knows what mechanations to upgrade to the latest version?

Because there are unfixable bugs in the older versions. I see very
little point in issuing "security updates" that fix individual buffer
overruns, when anyone who has the SQL-level access needed to trigger
one of those overruns can equally easily do "select cash_out(2)".
The only fix for that is an upgrade to 7.3.

I don't by any means have a problem with Red Hat issuing maintenance
releases against old versions (nor, as I said, do I have any objection
to a 7.2.4 community release; I just said it wasn't my decision to make).
What I am questioning is the value of fixing some security holes when
there are bigger, unfixable ones right next door. It wastes time that
could be spent on other work, and it may give DBAs a false sense of
security. "Sure I'm safe; I just got the latest security patch from
Red Hat, so my 6.5.3 Postgres must be bulletproof now!"

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-01-18 20:54:10 constraint defaults still print
Previous Message Justin Clift 2003-01-18 08:38:10 Re: v7.3.1 psql against a v7.2.x database ...