Subject: 7.5 release notes

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 00:25:43 -0400 (EDT)

I have completed the 7.5 release notes.  You can view them in HTML on
the developer web page.  I have marked a few items with question marks
that need to be addressed.  I am looking for improvements, even minor
ones.  Either send in a patch or committers can modify the file
directly.

Of course this file will be updated regularly all the way up to final
release to it isn't in its final form.

We don't have a /HISTORY file anymore so you have to view it via HTML.
/HISTORY will be in the final tarball, however.

Do people want a big-picture paragraph at the top talking about the
release?  Some releases get them, some don't, but this one could if
folks want it.

FYI, I have a NYC meeting on Monday so I am not going to OSCON until
Tuesday so I will be around regularly for 2-3 more days.

One thing we now need to look at is missing documentation.  The release
notes usually make missing documentation very glaring and I think we
need to work up a list of what is missing.  There isn't that much
missing except for the features we just finalized and stuff put in
during the past month of push to beta.  I am thinking of marking the
items needing docs right in the release notes with [DOCS] and that way
everyone can see what is needed.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email-masked]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---

From: Simon Riggs <[email-masked]>
Date: Sun, 25 Jul 2004 11:50:23 +0100

> ones.  Either send in a patch or committers can modify the file

Looks good. These take time and effort, much appreciated.

Forward-looking phrases
=======================

Overall, I'd ask that we don't refer back to what earlier releases
didn't do, or whatever limitations they were thought to have.

If a release has "new feature X", everybody can work out it wasn't there
in the last release. The phrasing is delicate so you describe the new
thing without running down the old.

e.g. (1)

Previous releases required the Unix emulation toolkit Cygwin for Win32
support.

to 

The server no longer relies upon Cygwin for Unix emulation under win32.

e.g. (2) 

Prior release had no such capability; there was no way to recover from a
statement failure in a transaction.

to 

Should a statement fail inside a transaction, there is now a way to
handle this error and continue processing.

(Of course, somebody will let me know about my Brit-style passive voice,
I'm sure...)

Migration 
=========
These release notes refer to "GUC"s, whereas the previous release notes
and the manual refers to "server configuration parameters". I understand
the former, but prefer the latter description for these user-focused
notes.

Also, it might be worth mentioning that pg_dump itself has also been
substantially improved, and now provides an improved upgrade path for
existing users.

Here's my attempt at a short paragraph for PITR...

Point-In-Time Recovery enhances Data Resilience
        
PostgreSQL can now recover from total disk failure using backups and
transaction log archives. Recovery can be controlled to stop at a
specified point in time or at some transaction in the past. Transaction
log archiving is automated and calls a user-supplied external program to
allow integration with external backup devices and related software.

> release?  Some releases get them, some don't, but this one could if

Yes, thats a good idea.

Best Regards, Simon Riggs

---

From: Jeff Davis <[email-masked]>
Date: Sun, 25 Jul 2004 03:51:36 -0700

> ones.  Either send in a patch or committers can modify the file

I don't understand the following passage:

"When matching GROUP BY names, prefer local FROM columns first, then
SELECT aliases, and then outer FROM columns (Tom) 

This change was made because it is considered more consistent than the
previous behavior."

Perhaps it could be more clear? I don't know where else I'd go to find
more thorough documentation on that subject.

Also, I've included a couple typo fixes below.

Regards,
	Jeff Davis

--- release.html.old    2004-07-25 03:06:28.000000000 -0700
+++ release.html        2004-07-25 03:10:21.000000000 -0700
@@ -99,7 +99,6 @@
      </p><p>      Before this change some queries would not use an
index if the data
       types did not exactly match. This improvement makes index usage
more
       intuitive and consistent.
-      match exactly
      </p></li><li><p>      New buffer replacement strategy that
improves caching (Jan)
      </p><p>      Prior releases use a least-recently-used (LRU) cache
to keep
       recently referenced pages in the cache. Unfortunately, the cache
@@ -129,7 +128,7 @@
       resulting in improved performance. The close relationship between
       our developers and users reporting problems allows us to make
       rapid and complex optimizer improvements that would be very
-      difficult for lose-source companies to emulate.
+      difficult for closed-source companies to emulate.
      </p></li><li><p>      Improve btree index performance for
duplicate keys (Dmitry Tkach, Tom)
      </p><p>      This improves the way indexes are scanned when many
duplicate       values exist in the index.

---

From: "Andrew Dunstan" <[email-masked]>
Date: Sun, 25 Jul 2004 08:32:48 -0400 (EDT)

> ones.  Either send in a patch or committers can modify the file

I presume we can also just make some comments ;-)

this item:

Add new GUC parameter to report useful information at the start of each
log line
should probably read "Add new GUC parameter log_line_prefix ....."

I think this item belongs to me, or me and Tom:

Replace the virtual_host and tcpip_socket parameters with a unified
listen_addresses parameter.

Conversely, Tom deserves joint billing for dollar quoting, as most of what I
did was based on his work.

David Fetter should be mentioned under the dollar quoting and plperl items,
as he did documentation for both.

Tom's implementation of a new flex-based lexer for psql is a significant
source code change which should be mentioned.

cheers

andrew

---

From: Bruno Wolff III <[email-masked]>
Date: Sun, 25 Jul 2004 09:29:37 -0500

On Sun, Jul 25, 2004 at 00:25:43 -0400,
> ones.  Either send in a patch or committers can modify the file

There is a typo (transaction is misspelled) in the following line:
Prior release had no such capability; there was no way to recover from a statement failure in a transation. This

"match exactly" at the end of the following appears to be spurious:

Before this change some queries would not use an index if the data types did not exactly match. This improvement makes index usage more intuitive and consistent. match exactly

In the following paragraph there appear to be two typos. I think
"optimizer make" should be "optimizer makes" and that "lose-source"
should be "closed-source".
 It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They are difficult to explain, but the result is that the optimizer make quicker and better choices in how to execute queries, resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very difficult for lose-source companies to emulate.

---

From: Gaetano Mendola <[email-masked]>
Date: Sun, 25 Jul 2004 19:00:10 +0200

|I have completed the 7.5 release notes.  You can view them in HTML on
|the developer web page.  I have marked a few items with question marks
|that need to be addressed.  I am looking for improvements, even minor
|ones.  Either send in a patch or committers can modify the file
|directly.

Did you forget to insert the autovacuum integrated ?

Regards
Gaetano Mendola

---

From: Tom Lane <[email-masked]>
Date: Sun, 25 Jul 2004 13:18:56 -0400

> This change was made because it is considered more consistent than the

That shouldn't be there at all, since the change was made and documented
in 7.4.3.  We don't normally duplicate previous release notes, do we?

			regards, tom lane

---

From: Tom Lane <[email-masked]>
Date: Sun, 25 Jul 2004 13:26:01 -0400

>  It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They…

I'd suggest removing the paragraph entirely, on the grounds that it is
content-free fluff.

			regards, tom lane

---

From: David Garamond <[email-masked]>
Date: Mon, 26 Jul 2004 01:25:25 +0700

> ones.  Either send in a patch or committers can modify the file

In E.1.1 Overview: "... This release supports Windows NT 4 and all later 
releases. It does not support earlier releases like Windows 95, 98, or 
ME because ... "

Win98 and WinME is released _after_ NT4. See

  http://www.computerhope.com/history/windows.htm

Perhaps it's better to say: "We only support NT-based Windows such as 
NT4, Win2k/XP/2003/later. Old 9x-based Windows versions such as 
Win95/98/Me are not supported because ..."

Btw, can 7.5 run on WinCE/XP Media Center/XP SP2/etc?

-- 
dave

---

From: Alvaro Herrera <[email-masked]>
Date: Sun, 25 Jul 2004 17:01:09 -0400

On Mon, Jul 26, 2004 at 02:22:21AM +0200, Gaetano Mendola wrote:
> In the release not I can read:
> 
> #Allow arbitrary row expressions (Tom)
> 
> This allows columns to contain arbitrary composite types
> like rows from other tables. [SNIPPED]
> 
> Wasn't this alread true on 7.4 ?

No, this is a new feature.  Did you try inserting anything into the
tables?  How about using rowtypes as function parameters?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"If you have nothing to say, maybe you need just the right tool to help you
not say it."                   (New York Times, about Microsoft PowerPoint)

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 18:10:44 -0400 (EDT)

Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

It isn't applied yet.

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 19:55:50 -0400 (EDT)

> Looks good. These take time and effort, much appreciated.

I understand your reason for making these changes.  However, I am unsure
if your new wording is as clear as the previous one.  Our reliance on
Cygwin and inability to prevent an error from aborting a transaction
were limitation and it seems clearer to just state that we have fixed
them rather than try to sugar-code our previous limitations.

Marketing-wise, I think you are right, but from an honesty/clarity
perspective, I think the current wording is better.  What I could do is
remove some of the later references where we were talking updating the
system catalog to do various things.  I am not sure it is needed. 

Comments?

> the former, but prefer the latter description for these user-focused

Updated.

> substantially improved, and now provides an improved upgrade path for

It is mentioned as the top item in the pg_dump section.  It doesn't seem
like a migration issue to me though.  Is it a major feature?

> allow integration with external backup devices and related software.

We can improve the wording, but if the motivation is to reduced saying
bad things about our previous functionality, let me explain my
perspective.

Basically, my goal with these release notes is to make it as clear as
possible why this new feature would be valuable to the reader.  If it
makes our previous release look bad, so be it.  For me, clarity and
candor gain a lot more credibility than trying to cover over missing
functionality in the past.  I am not saying we have to be so honest that
we bash PostgreSQL, but in cases where we adjust wording to try to
prevent ourselves from looking bad, it is best to be honest and clear
about our limitations.  I think in the long run it gains us lots of
credibility (and ultimately volunteers).

> > release?  Some releases get them, some don't, but this one could if

OK.

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:12:24 -0400 (EDT)

> more thorough documentation on that subject.

Item removed.  Tom said it was already in 7.4.3.

I made the adjustments below.

---------------------------------------------------------------------------

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:12:41 -0400 (EDT)

> "match exactly" at the end of the following appears to be spurious:

Yes, removed.

>  It is difficult to explain all the optimizer improvements that go into a release like this. They involve complex adjustments to the logic used to select indexes, join methods, and join order. They…

Fixed.>

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:13:39 -0400 (EDT)

> in 7.4.3.  We don't normally duplicate previous release notes, do we?

Agreed. Removed.

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:16:58 -0400 (EDT)

All added. Thanks.

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:19:43 -0400 (EDT)

Adjustment made:

        http://pgfoundry.org/projects/pginstaller</ulink>. This release
        supports  NT-based Windows releases like NT4, Win2k, XP, Win2003.
        Older releases like Windows 95, 98, and ME are not supported because
        these operating systems do not have the infrastructure to
        support PostgreSQL.

David Garamond wrote:
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:21:52 -0400 (EDT)

All fixed.  Thanks.

Bruno Wolff III wrote:
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to [email-masked])
>

---

From: Gaetano Mendola <[email-masked]>
Date: Mon, 26 Jul 2004 02:22:21 +0200

See:

kalman=# select version();
                                                  version
---------------------------------------------------------------------------------------------------------
  PostgreSQL 7.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
(1 row)

kalman=# create table test ( a varchar, b varchar, c varchar );
CREATE TABLE
kalman=# create table test1 ( d integer, e test );
CREATE TABLE
kalman=# select * from test1;
  d | e
---+---
(0 rows)

kalman=# select e from test1;
  e
---
(0 rows)

kalman=# select (e).a from test1;
  a
---
(0 rows)

Regards
Gaetano Mendola

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 20:23:49 -0400 (EDT)

> I'd suggest removing the paragraph entirely, on the grounds that it is

Hey, that's your content-free fluff.  :-)

You make major optimizer improvements in every release, but they are so
complex it is impossible to explain them to people.  This paragraph
tries to address that.

However, since you don't like it, I will remove it entirely.  If you
change your mind we can re-add it.

---

From: Simon Riggs <[email-masked]>
Date: Mon, 26 Jul 2004 02:31:47 +0100

> > > ones.  Either send in a patch or committers can modify the file

Those were just examples of a suggested style change for some items.

> possible why this new feature would be valuable to the reader.  

Completely Agree.

> If it makes our previous release look bad, so be it. 

Oh.

>  For me, clarity and

I see this as merely a half-full/half-empty viewpoint issue.

Honesty and clarity are wonderful things and I subscribe to them. Using
them only to describe your own viewpoint is not a reasonable point to
make in a hopefully rational discussion about writing style...

I'll go back to my docs now, but I guess we may relive this again when
you see some of the honest, clear and positive changes I am suggesting.
:)

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 25 Jul 2004 21:43:40 -0400 (EDT)

> you see some of the honest, clear and positive changes I am suggesting.

I wasn't suggesting yours were dishonest.  I was saying that I was
aiming for the clearest style whether is makes PostgreSQL look good or
not.  I figured saying "in the past you had to do X" was clearer than
saying "you don't have to do X anymore".

I am, of course, am open to the community's feedback on this.

---

From: Tom Lane <[email-masked]>
Date: Mon, 26 Jul 2004 02:17:10 -0400

> tables?

Postgres has always accepted this syntax, but it has not done anything
useful in many years, and when it last did do something useful the
semantics were quite a bit different :-(

Elein has standing to bash me about the change of semantics, but I don't
think the rest of you do ...

			regards, tom lane