Thread: 8.0 questions
Dear postgres community, I would like to know what are the significant changes and new features introduced in Postgres 8.0 which warranted the major version number increment. From the postres website it is not very clear as I can only find technical changelogs for the beta releases. //Artem
On Thu, 2004-10-07 at 14:48 -0400, Artem Litvinovich wrote: > Dear postgres community, > > I would like to know what are the significant changes and new features > introduced in Postgres 8.0 which warranted the major version number > increment. From the postres website it is not very clear as I can only > find technical changelogs for the beta releases. > > //Artem > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend I think that if you look in the postgresql advocacy list archives, it was first mentioned by Josh Berkus as to why the change to 8.0 voila: http://archives.postgresql.org/pgsql-advocacy/2004-08/msg00022.php hth, Robby -- /*************************************** * Robby Russell | Owner.Developer.Geek * PLANET ARGON | www.planetargon.com * Portland, OR | robby@planetargon.com * 503.351.4730 | blog.planetargon.com * PHP/PostgreSQL Hosting & Development ****************************************/
Attachment
Robby Russell <robby@planetargon.com> writes: > On Thu, 2004-10-07 at 14:48 -0400, Artem Litvinovich wrote: >> I would like to know what are the significant changes and new features >> introduced in Postgres 8.0 which warranted the major version number >> increment. > I think that if you look in the postgresql advocacy list archives, it > was first mentioned by Josh Berkus as to why the change to 8.0 > http://archives.postgresql.org/pgsql-advocacy/2004-08/msg00022.php Also see http://developer.postgresql.org/docs/postgres/release.html#RELEASE-8-0 regards, tom lane
Hi! A quite impressive list of changes in version 8.0.0. ... But the question from me is: When is it done? We have a lot of 7.2.5 versions running which badly needs an update, but if version 8.0.0 comes in the near future, we could surely hold out a while longer and go for the top of the line. I'm not asking for a specified date but do we have to wait until next year or is it just a couple months or shorter away ? Best regars, Thomas M. Madsen. > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane > Sent: 8. oktober 2004 04:04 > To: Robby Russell > Cc: alit@vtsystems.com; pgsql-general@postgresql.org > Subject: Re: [GENERAL] 8.0 questions > > > Robby Russell <robby@planetargon.com> writes: > > On Thu, 2004-10-07 at 14:48 -0400, Artem Litvinovich wrote: > >> I would like to know what are the significant changes and new > >> features introduced in Postgres 8.0 which warranted the > major version > >> number increment. > > > I think that if you look in the postgresql advocacy list > archives, it > > was first mentioned by Josh Berkus as to why the change to 8.0 > > http://archives.postgresql.org/pgsql-advocacy/2004-08/msg00022.php > > Also see > http://developer.postgresql.org/docs/postgres/release.html#RELEASE-8-0 regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
Thomas Madsen wrote: > A quite impressive list of changes in version 8.0.0. ... > > But the question from me is: When is it done? Two words: Nobody knows. Beta cycle is usually at least 2-3 months. First beta is in Aug. So a release is probably Nov at the earliest. > We have a lot of 7.2.5 versions running which badly needs an update, but > if version 8.0.0 comes in the near future, we could surely hold out a > while longer and go for the top of the line. Unless you need a specific feature of 8.0 (savepoint, PITR, migration to Windows :)), it's generally recommended to use 7.4.5. 8.0's previous name was 7.5 and it was renamed to X.0 to reflect the fact that it is not believed to be more robust than 7.4. -- dave
David Garamond wrote: > Thomas Madsen wrote: > >> A quite impressive list of changes in version 8.0.0. ... >> >> But the question from me is: When is it done? > > > Two words: Nobody knows. Beta cycle is usually at least 2-3 months. > First beta is in Aug. So a release is probably Nov at the earliest. > >> We have a lot of 7.2.5 versions running which badly needs an update, but >> if version 8.0.0 comes in the near future, we could surely hold out a >> while longer and go for the top of the line. > > > Unless you need a specific feature of 8.0 (savepoint, PITR, migration to > Windows :)), it's generally recommended to use 7.4.5. 8.0's previous > name was 7.5 and it was renamed to X.0 to reflect the fact that it is > not believed to be more robust than 7.4. Wait wait. All X.0 version are not believed more robust then Y.Z with Y < X and Z >> 0 Anyway is a general consensus that the win32 8.0 version is not more robust than his counterpart *nix 8.0 this because lot of code already mature in *nix environment is new in the win32 one. Regards Gaetano Mendola
David Garamond <lists@zara.6.isreserved.com> writes: > > We have a lot of 7.2.5 versions running which badly needs an update, but > > if version 8.0.0 comes in the near future, we could surely hold out a > > while longer and go for the top of the line. > > Unless you need a specific feature of 8.0 (savepoint, PITR, migration to > Windows :)), it's generally recommended to use 7.4.5. 8.0's previous name was > 7.5 and it was renamed to X.0 to reflect the fact that it is not believed to be > more robust than 7.4. Another reason to move to 7.4.5 would be that each version introduced changes in behaviour. You're going to be dealing with minor headaches from things like '' not being a valid integer any more (it used to parse as 0 now it's an error). It'll be easier to do that in two steps than to deal with them all at once. -- greg
>>>>> "GS" == Greg Stark <gsstark@mit.edu> writes: GS> David Garamond <lists@zara.6.isreserved.com> writes: GS> Another reason to move to 7.4.5 would be that each version GS> introduced changes in behaviour. You're going to be dealing with GS> minor headaches from things like '' not being a valid integer any GS> more (it used to parse as 0 now it's an error). It'll be easier to GS> do that in two steps than to deal with them all at once. I disagree. If you're in your app and need to modify code, it is easier to make all the changes at once and regression test them, than do it twice: you're testing workload is likely to be more if you split the changes. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Vivek Khera wrote: >>>>>>"GS" == Greg Stark <gsstark@mit.edu> writes: > > GS> David Garamond <lists@zara.6.isreserved.com> writes: > > GS> Another reason to move to 7.4.5 would be that each version > GS> introduced changes in behaviour. You're going to be dealing with > GS> minor headaches from things like '' not being a valid integer any > GS> more (it used to parse as 0 now it's an error). It'll be easier to > GS> do that in two steps than to deal with them all at once. > > I disagree. If you're in your app and need to modify code, it is > easier to make all the changes at once and regression test them, than > do it twice: you're testing workload is likely to be more if you split > the changes. That depends whether you actually want to modify your app code or whether you just want to upgrade the db software. Also, it depends on how much stability you want in the production environment. I personally would still trust 7.4.5 if I want the minimum amount of headache. True, testing twice (one for 7.4.5 and one for 8.0) might total in more workload, but potentially has the least amount of downtime possibility. -- dave