Date: Thu, 23 Oct 2003 07:02:26 -0400
From: Michael Brusser <michael@synchronicity.com>
Subject: Re: 7.4 compatibility question
In-reply-to: <200310221804.h9MI4wA01230@candle.pha.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Neil Conway <neilc@samurai.com>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Reply-To: michael@synchronicity.com
Message-id: <DEEIJKLFNJGBEMBLBAHCGEEKDNAA.michael@synchronicity.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal

> -----Original Message-----
> From: Bruce Momjian 
...
> The big question is whether the current release notes hit he right
> balanced.  Do they for you?

The last time I read the notes was when we upgraded to 7.3.4.
I'll pick up couple entries from Release Notes and the HISTORY file
(which we always read) for examples.

PostgreSQL now supports the ALTER TABLE ... DROP COLUMN functionality. 
 => this is entirely sufficient. Detailed info can be found in the docs.

Optimizer improvements
 => this tells me nothing. I suppose this could be a minor internal code
tweak, which does not affect me. On the other hand this could be a major
breakthrough, so now I can run some stupid query which would take
a week to complete in the previous release. How do I know? 

Fix to_ascii() buffer overruns
 => I don't think I need any more details here

Work around buggy strxfrm() present in some Solaris releases
 => if we did not suffer from this (big thanks for fixing!) I would've
never guessed how it may manifest itself and affect the database,
even though this alone could be a strong reason for upgrade.

If you think this would take too much space and bloat the document,
then maybe the best solution is to have a reference number:
 Bug# 123 : Work around ...
Then I could go to some http://postgres../bugtrack enter this number
and learn more.

Mike.