7.5 release notes

On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote:

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.

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.

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.

Yes, thats a good idea.

Best Regards, Simon Riggs

On Sat, 2004-07-24 at 21:25, Bruce Momjian wrote:

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.

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.

Bruce Momjian said:

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.

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

On Sun, Jul 25, 2004 at 00:25:43 -0400,
Bruce Momjian <pgman@candle.pha.pa.us> wrote:

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.

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote:

|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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBA+cZ7UpzwH2SGd4RAgQwAKD11vpcxmsjkwdJABDMEpe27NS0HQCg1DVq
qnZ1ZENnFUVD0nl358vpxj4=
=WE9n
-----END PGP SIGNATURE-----

Jeff Davis <jdavis-pgsql@empires.org> writes:

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."

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

Bruno Wolff III <bruno@wolff.to> writes:

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.

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

regards, tom lane

Bruce Momjian wrote:

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.

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

Btw, can 7.5 run on WinCE

No.

/XP Media Center/

Probably, but AFAIK not tested.

XP SP2

Yes (haven't tested with the very latest versions of the SP, but it
works with the earlier ones)

/etc?

Works fine on the PDC build of Longhorn...

//Magnus

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)

Gaetano Mendola wrote:
[ PGP not available, raw data follows ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote:

|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 ?

It isn't applied yet.

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

Simon Riggs wrote:

On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote:

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.

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...)

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?

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.

Updated.

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.

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?

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.

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).

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.

Yes, thats a good idea.

OK.

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

Jeff Davis wrote:

On Sat, 2004-07-24 at 21:25, Bruce Momjian wrote:

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.

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.

Item removed. Tom said it was already in 7.4.3.

I made the adjustments below.

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

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.

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

Bruno Wolff III wrote:

On Sun, Jul 25, 2004 at 00:25:43 -0400,
Bruce Momjian <pgman@candle.pha.pa.us> wrote:

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.

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:

Yes, removed.

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.

Fixed.>

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

Tom Lane wrote:

Jeff Davis <jdavis-pgsql@empires.org> writes:

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."

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?

Agreed. Removed.

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

All added. Thanks.

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

Andrew Dunstan wrote:

Bruce Momjian said:

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.

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

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

Adjustment made:

http://pgfoundry.org/projects/pginstaller&lt;/ulink&gt;. 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:

Bruce Momjian wrote:

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.

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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

All fixed. Thanks.

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

Bruno Wolff III wrote:

On Sun, Jul 25, 2004 at 00:25:43 -0400,
Bruce Momjian <pgman@candle.pha.pa.us> wrote:

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.

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.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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

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 ?

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

\Tom Lane wrote:

Bruno Wolff III <bruno@wolff.to> writes:

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.

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

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.

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

On Mon, 2004-07-26 at 00:55, Bruce Momjian wrote:

Simon Riggs wrote:

On Sun, 2004-07-25 at 05:25, Bruce Momjian wrote:

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.

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

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.

Completely Agree.

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

Oh.

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).

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.
:)

--
Best Regards, Simon Riggs

Simon Riggs wrote:

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).

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.
:)

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.

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

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

On Mon, Jul 26, 2004 at 02:22:21AM +0200, Gaetano Mendola wrote:

In the release not I can read:
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?

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