Thread: 7.4 status
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.) Perhaps it is time to start looking at a final release date for 7.4? -- 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, Pennsylvania19073
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: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend >
"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
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
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, Pennsylvania19073
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,
Pennsylvania19073
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
Attachment
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