7.4 status

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Perhaps it is time to start looking at a final release date for 7.4?

At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?

regards, tom lane

Should we maybe get a Beta4 out now that everything is caught up code
wise? Is anyone still sitting on something (other then the translations
stuff) that should be in v7.4?

On Mon, 29 Sep 2003, Tom Lane wrote:

On Mon, 2003-09-29 at 14:57, Bruce Momjian wrote:

I have emptied the patch queue, and have updated the HISTORY file for
7.4. I am looking for any improvements to that file. (I have to move
it to SGML soon.)

A patch that improves HISTORY is attached. I added a few bullet items to
the "highlights of this release section" that are IMHO important,
removed the mention of hash indexes (IMHO, they are still inappropriate
for production use, just less so), fixed some spelling mistakes, and
clarified a few entries.

Please apply.

-Neil

"Marc G. Fournier" <scrappy@postgresql.org> writes:

Should we maybe get a Beta4 out now that everything is caught up code
wise? Is anyone still sitting on something (other then the translations
stuff) that should be in v7.4?

We still have several open items in Bruce's list, but maybe we can
resolve them soon. Tentatively set a beta for Wed the 1st, maybe?

regards, tom lane

Patch applied. Thanks.

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

Neil Conway wrote:

On Mon, 2003-09-29 at 14:57, Bruce Momjian wrote:

I have emptied the patch queue, and have updated the HISTORY file for
7.4. I am looking for any improvements to that file. (I have to move
it to SGML soon.)

A patch that improves HISTORY is attached. I added a few bullet items to
the "highlights of this release section" that are IMHO important,
removed the mention of hash indexes (IMHO, they are still inappropriate
for production use, just less so), fixed some spelling mistakes, and
clarified a few entries.

Please apply.

-Neil

[ Attachment, skipping... ]

-- 
  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 writes:

At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?

Yes, I think we're ready for a string freeze. Alvaro, do you have
anything you still want to submit in that area?

--
Peter Eisentraut peter_e@gmx.net

On Mon, Sep 29, 2003 at 11:50:23PM +0200, Peter Eisentraut wrote:

Tom Lane writes:

At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?

Yes, I think we're ready for a string freeze. Alvaro, do you have
anything you still want to submit in that area?

The only things left that I can see are

#: commands/tablecmds.c:4093
msgid "tables \"%s\" already has a TOAST table"
"tables" -> "table"

#: commands/user.c:651 commands/user.c:1357
msgid "sysid %d is already assigned"
"sysid" -> "user ID"? Not sure, maybe it can be a group ID.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)

Neil Conway <neilc@samurai.com> writes:

SSL
! Major improvements in SSL performance and security

Did we actually add any "security" to the SSL code? Performance and
reliability, maybe, but I didn't think we'd done anything to the
security algorithms per se. Did I miss something?

Index Growth Prevention
Allow free space map to efficiently reused empty index pages,
! and other free space management improvements.

"reused" -> "reuse"

! ANSI joins are now fully optimized

"better" optimized maybe; I wouldn't say we're done with that issue yet.
(In particular, I want to look into reordering outer joins sometime.)

! Faster regular expression code

We could tout more functionality too, since the new regex package
has a lot of advanced stuff that wasn't there before.

* The server-side autocommit setting was removed an reimplemented
in client applications and languages.

"an" -> "and"

! * Error message wording has changed dramatically in this release,
and error codes have been added.

"Substantially" might be a better term anyway?

* ANSI joins may behave differently because they are now fully optimized

See above

* Date values now must match the ordering specified by DateStyle

... except that YYYY-MM-DD (with 3 or more digits for year) is always
accepted.

regards, tom lane

Tom Lane wrote:

Neil Conway <neilc@samurai.com> writes:

SSL
! Major improvements in SSL performance and security

Did we actually add any "security" to the SSL code? Performance and
reliability, maybe, but I didn't think we'd done anything to the
security algorithms per se. Did I miss something?

I changed the wording to reliability. We did so some security by
changing the rate of key negotiation, but it isn't substantial.

Index Growth Prevention
Allow free space map to efficiently reused empty index pages,
! and other free space management improvements.

"reused" -> "reuse"

Done.

! ANSI joins are now fully optimized

"better" optimized maybe; I wouldn't say we're done with that issue yet.
(In particular, I want to look into reordering outer joins sometime.)

Yep.

! Faster regular expression code

We could tout more functionality too, since the new regex package
has a lot of advanced stuff that wasn't there before.

Added "more powerful"

* The server-side autocommit setting was removed an reimplemented
in client applications and languages.

"an" -> "and"

Done.

! * Error message wording has changed dramatically in this release,
and error codes have been added.

"Substantially" might be a better term anyway?

Yep.

* ANSI joins may behave differently because they are now fully optimized

See above

Changed to "better optimized"

* Date values now must match the ordering specified by DateStyle

... except that YYYY-MM-DD (with 3 or more digits for year) is always
accepted.

Changed to:

* Ambiguous date values now must match the ordering specified by DateStyle

Committed to CVS.

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

Bruce Momjian kirjutas T, 30.09.2003 kell 02:16:

Tom Lane wrote:

! Faster regular expression code

We could tout more functionality too, since the new regex package
has a lot of advanced stuff that wasn't there before.

Added "more powerful"

This wording covers nicely possible incompatibilities too ;)

--------------
Hannu

On Mon, Sep 29, 2003 at 11:50:23PM +0200, Peter Eisentraut wrote:

Tom Lane writes:

At the very least we need to set a strings freeze soon, so the
translators can catch up. Peter, are you getting close to done with the
message revisions you've been making?

Yes, I think we're ready for a string freeze. Alvaro, do you have
anything you still want to submit in that area?

Does this count a string change? :)

Patrick

Alvaro Herrera writes:

The only things left that I can see are

#: commands/tablecmds.c:4093
msgid "tables \"%s\" already has a TOAST table"
"tables" -> "table"

Fixed.

#: commands/user.c:651 commands/user.c:1357
msgid "sysid %d is already assigned"
"sysid" -> "user ID"? Not sure, maybe it can be a group ID.

Changed to "user ID" and "group ID". Sounds better to me too.

--
Peter Eisentraut peter_e@gmx.net

Patrick Welche writes:

Does this count a string change? :)

Yes, but it's also a documentation bug fix.

Anyway, you got it in before the freeze. :)

--
Peter Eisentraut peter_e@gmx.net

While reviewing someone else's translation of pg_dump I noted that the
phrase "ACL list" is used in a couple of places. However ACL stands for
"Access Control List", so the term "ACL list" seems redundant.

Maybe it should be replaced with plain "ACL"?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)

Alvaro Herrera writes:

While reviewing someone else's translation of pg_dump I noted that the
phrase "ACL list" is used in a couple of places. However ACL stands for
"Access Control List", so the term "ACL list" seems redundant.

These kinds of redundancies are pretty common for the sake of clarity and
the flow of the language. Even major so-called "Usage Panels" accept
them.

The thing being parsed here is an array of datums of type "aclitem", so
the term "ACL list" is rather unclear anyway. But I hesitate to change it
now because we wanted to call a string freeze.

--
Peter Eisentraut peter_e@gmx.net