Thread: Not 7.5, but 8.0 ?
Folks, Of course, while I was editing press releases at 2am, I started thinking about our next version. It seems certain that the next release, in 6-9 months, will have at a minimum the Windows port and ARC, if not Slony-I as well. Given all that, don't people think it's time to jump to 8.0? Seems like even 7.4 is hardly recognizable as the same database as 7.0. I'm posting this to both Advocacy and Hackers because I think that some people will have rather different points of view on the issue. But I wanted to start a discussion early this time. No flamewars, please! We all want PostgreSQL to be the best possible database. -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes: > It seems certain that the next release, in 6-9 months, will have at > a minimum the Windows port and ARC, if not Slony-I as well. > > Given all that, don't people think it's time to jump to 8.0? It seems a little premature to speculate on what features may or may not be present in 6 to 9 months time. Why make this decision now, when we don't even know what will be in the next release, rather than at the end of the development cycle? -Neil
Josh Berkus writes: > Given all that, don't people think it's time to jump to 8.0? As has been said before, many people think that a Windows port is the least interesting feature ever to happen to PostgreSQL, so you're going to have to come up with better reasons. Also note that most major number changes in the past weren't because the features were cool, but because the project has moved to a new phase. I don't see any such move happening. -- Peter Eisentraut peter_e@gmx.net
Peter, > As has been said before, many people think that a Windows port is the > least interesting feature ever to happen to PostgreSQL, so you're going to > have to come up with better reasons. Yeah, I'm more interested in ARC and replication ... and the SQL standardization that just went into 7.4. > Also note that most major number > changes in the past weren't because the features were cool, but because > the project has moved to a new phase. I don't see any such move > happening. Now that is interesting. I missed that. Can you explain how that worked with 7.0? -- Josh Berkus Aglio Database Solutions San Francisco
Hello, If Win32 actually makes it into 7.5 then yes I believe 8.0 would be appropriate. Sincerely, Joshua D. Drake On Mon, 17 Nov 2003, Josh Berkus wrote: > Folks, > > Of course, while I was editing press releases at 2am, I started thinking about > our next version. It seems certain that the next release, in 6-9 months, > will have at a minimum the Windows port and ARC, if not Slony-I as well. > > Given all that, don't people think it's time to jump to 8.0? Seems like > even 7.4 is hardly recognizable as the same database as 7.0. > > I'm posting this to both Advocacy and Hackers because I think that some people > will have rather different points of view on the issue. But I wanted to > start a discussion early this time. No flamewars, please! We all want > PostgreSQL to be the best possible database. > > -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead
Peter Eisentraut wrote: > As has been said before, many people think that a Windows port is the > least interesting feature ever to happen to PostgreSQL, so you're going to > have to come up with better reasons. Also note that most major number > changes in the past weren't because the features were cool, but because > the project has moved to a new phase. I don't see any such move > happening. What happens if Postgres hits 7.9 but still hasn't reached the next phase? :)
> As has been said before, many people think that a Windows port is the > least interesting feature ever to happen to PostgreSQL, so you're going to Yes but these are people running Unix/Linux/BSD not Windows ;) > have to come up with better reasons. Also note that most major number > changes in the past weren't because the features were cool, but because > the project has moved to a new phase. I don't see any such move > happening. > > -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead
On Mon, 17 Nov 2003, Josh Berkus wrote: > Given all that, don't people think it's time to jump to 8.0? Seems like > even 7.4 is hardly recognizable as the same database as 7.0. Discussion like this tends to be more for just before beta, once we have an idea what actually made it in :) You be putting the cart before the horse, eh?
Josh Berkus wrote: > > Also note that most major number > > changes in the past weren't because the features were cool, but because > > the project has moved to a new phase. I don't see any such move > > happening. > > Now that is interesting. I missed that. Can you explain how that worked > with 7.0? We stopped crashing in 7.0, or was it 6.5 --- that was our milestone, I think. :-) -- 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
Oops! josh@agliodbs.com (Josh Berkus) was seen spray-painting on a wall:
> Given all that, don't people think it's time to jump to 8.0? Seems
> like even 7.4 is hardly recognizable as the same database as 7.0.
If wishes were fishes... Shouldn't we see what interesting features
actually _do_ make it in?
If Win32 support does get ready, and we get recursive queries (I'll
point out different TODO items :-)) and Slony-1, PITR, and cache
improvements make it in, then perhaps it's time to call it 8.0. A
"cvs update -Pd" doesn't get me that yet, so it seems early.
I'd _almost_ buy the story that 7.4 should have been called 8.0,
although that _didn't_ happen because it 'just missed' PITR and Win32.
The amusing approach would be to jump straight to 8.1 :-).
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/postgresql.html
..you could spend *all day* customizing the title bar. Believe me. I
speak from experience." -- Matt Welsh
В Втр, 18.11.2003, в 00:43, William Yu пишет: > What happens if Postgres hits 7.9 but still hasn't reached the next > phase? :) Easy - 7.10. -- Markus Bertheau <twanger@bluetwanger.de>
Maybe the criteria for 8.0 should be in place upgrades... that would be
a major shift in the landscape of PostgreSQL...
Robert Treat
On Mon, 2003-11-17 at 21:20, Christopher Browne wrote:
> Oops! josh@agliodbs.com (Josh Berkus) was seen spray-painting on a wall:
> > Given all that, don't people think it's time to jump to 8.0? Seems
> > like even 7.4 is hardly recognizable as the same database as 7.0.
>
> If wishes were fishes... Shouldn't we see what interesting features
> actually _do_ make it in?
>
> If Win32 support does get ready, and we get recursive queries (I'll
> point out different TODO items :-)) and Slony-1, PITR, and cache
> improvements make it in, then perhaps it's time to call it 8.0. A
> "cvs update -Pd" doesn't get me that yet, so it seems early.
>
> I'd _almost_ buy the story that 7.4 should have been called 8.0,
> although that _didn't_ happen because it 'just missed' PITR and Win32.
>
> The amusing approach would be to jump straight to 8.1 :-).
> --
> wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
> http://www.ntlug.org/~cbbrowne/postgresql.html
> ..you could spend *all day* customizing the title bar. Believe me. I
> speak from experience." -- Matt Welsh
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of
> OSes already. What's so exciting about one more? Even if it is a
> pathologically hard OS to port to. Just because it was hard doesn't mean it's
> useful.
>
Absolutely correct.
PostgreSQL runs on so many platforms. I cannot see a reason why we
should put effort in an inheritly nasty operating system which will
cause A LOT of pain in the future.
I can already hear the question we will have to face ...
People using PostgreSQL are not MySQL or Access people - they know why
they are using Linux. I have seen somebody asking for Windows once or
twice in 4 yours. Is it worth the effort?
Of course, many people use Windows - I can understand that for desktop
PCs but personally I am in a bit different situation. We support
PostgreSQL which means that people will cut my head off if something
does not work. I don't trust Windows and I don't want to hunt bugs in
PostgreSQL which are caused by an inferious and inheritly nasty
operating system.
As far as versioning is concerned: I am not in favour of pumping the
version number to number. Here in Austria we call those things
"versionitis" - it is a Windows-disease and should be cured.
We have never lost against a different database because of a lower
version number.
I'd make 8.0 a "network release" meaning that 2pc, replication and
things like that are supported.
Regards,
Hans V1.0
--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
Joshua D. Drake wrote: > Hello, > > If Win32 actually makes it into 7.5 then yes I believe 8.0 would be > appropriate. It might be interesting to track Oracle's version number viz. its feature list. IOW, a PostgreSQL 8.0 database would be feature equivalent to an Oracle 8.0 database. That would mean: 1) PITR 2) Distributed Tx 3) Replication 4) Nested Tx 5) PL/SQL Exception Handling IMHO, a major version number jump should at least match the delta in features one finds in the commercial segment with their major version number bumps. Otherwise, I suspect it would be viewed as window dressing... Could be wrong, though... Mike Mascari mascarm@mascari.com
Christopher Browne wrote: > Oops! josh@agliodbs.com (Josh Berkus) was seen spray-painting on a wall: >> Given all that, don't people think it's time to jump to 8.0? Seems >> like even 7.4 is hardly recognizable as the same database as 7.0. > > If wishes were fishes... Shouldn't we see what interesting features > actually _do_ make it in? > > If Win32 support does get ready, and we get recursive queries (I'll > point out different TODO items :-)) and Slony-1, PITR, and cache > improvements make it in, then perhaps it's time to call it 8.0. A > "cvs update -Pd" doesn't get me that yet, so it seems early. > > I'd _almost_ buy the story that 7.4 should have been called 8.0, > although that _didn't_ happen because it 'just missed' PITR and Win32. > > The amusing approach would be to jump straight to 8.1 :-). The real fun would be to let it start as 8, then 8.1 and so on ... Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Josh Berkus <josh@agliodbs.com> writes:
> Peter wrote:
>> Also note that most major number
>> changes in the past weren't because the features were cool, but because
>> the project has moved to a new phase. I don't see any such move
>> happening.
> Now that is interesting. I missed that. Can you explain how that worked
> with 7.0?
Personally I thought that the 6.5->7.0 jump was a mistake ... but that's
water over the dam now.
I would be willing to call a PG release 8.0 when it has built-in
replication support --- that would be the sort of major-league
functionality jump that would justify a top-number bump.
There are not that many other plausible reasons for a top-number bump
that I can think of right now. PG is really getting to be a pretty
mature product, and ISTM that should be reflected in a disinclination
to call it "all new".
You can be dead certain that a Windows port will not be sufficient
reason to call it 8.0. Perhaps 6.6.6 would the right starting version
number for that one ;-)
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> wrote: <snip> > I would be willing to call a PG release 8.0 when it has built-in > replication support --- that would be the sort of major-league > functionality jump that would justify a top-number bump. ACK. A major release (for me) implies some really major improvement. Replication would be such a thing. BTW: is there anything working yet in this direction ? I know several "userland" implementations (w/ triggers), and I also doing symetric (masterless) replication in my middleware framework, but when will pgsql be able to do it by itself ? And when will probably load balancing come ? hmm, which commerical RDBMS (beside oracle) provide this already ? <snip> > You can be dead certain that a Windows port will not be sufficient > reason to call it 8.0. Perhaps 6.6.6 would the right starting version > number for that one ;-) *rofl* cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------
Enrico Weigelt wrote: > * Tom Lane <tgl@sss.pgh.pa.us> wrote: > > <snip> > > I would be willing to call a PG release 8.0 when it has built-in > > replication support --- that would be the sort of major-league > > functionality jump that would justify a top-number bump. > ACK. > A major release (for me) implies some really major improvement. > Replication would be such a thing. > > BTW: is there anything working yet in this direction ? > I know several "userland" implementations (w/ triggers), and I also > doing symetric (masterless) replication in my middleware framework, > but when will pgsql be able to do it by itself ? > And when will probably load balancing come ? All replication work is being done as add-ons because then people can choose the replication solution that works best for them. We don't think a single solution can fit all needs. -- 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
> BTW: is there anything working yet in this direction ? > I know several "userland" implementations (w/ triggers), and I also > doing symetric (masterless) replication in my middleware framework, > but when will pgsql be able to do it by itself ? There is only one production and shipping replication that does not require triggers that I know of and that is ours (Command Prompt). It is also not a userland app but actually part of the PostgreSQL engine. There is also ERServer which was first (?) but it tends to be a bit of a beast to maintain. There is Slony-I which is showing promise but is a Trigger based option. Others include Peer Direct (Which I believe is query based) and PgCluster which is query based. Each solution has pro's and cons. Slony-I for example appears to be better when doing mass updates or deletes than Replicator. On the argument of significant features for 7.5: Win32 Native PITR Nested Transactions Background Writer.... J > And when will probably load balancing come ? > > hmm, which commerical RDBMS (beside oracle) provide this already ? > > <snip> > >>You can be dead certain that a Windows port will not be sufficient >>reason to call it 8.0. Perhaps 6.6.6 would the right starting version >>number for that one ;-) > > *rofl* > > cu -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
* Bruce Momjian <pgman@candle.pha.pa.us> wrote: <snip> > All replication work is being done as add-ons because then people can > choose the replication solution that works best for them. We don't > think a single solution can fit all needs. hmm. I didn't have the time yet to google about them ... Where do the come in ? Hast the postmaster to be patched and recompiled ? Is there anywhere an overview about them ? Are they publically available w/o fees ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------
* Joshua D. Drake <jd@commandprompt.com> wrote: <snip> > There is only one production and shipping replication that does not > require triggers that I know of and that is ours (Command Prompt). > It is also not a userland app but actually part of the PostgreSQL engine. Ah. Has pgsql to be patched for that or can it be simply dropped-in like external (C) functions/procedures ? What about lazy replication (i.e. when some node is running but not online for a while), masterless replication (all nodes are equal) or journaling ? My application/framework-level solves this, but a) requires some special table layout (first attrs have to be inode+mtime), b) not suited for high update-rates (relly too slow for that) but it is already working quite stable for several years :) <snip> > Each solution has pro's and cons. Slony-I for example appears to be > better when doing mass updates or deletes than Replicator. yeah, on subsequent mass-updates on just one host per table at certain time, my stuff is also good, since it works w/ batching. but when multiple hosts do heavy updates on the same table, it may run into conflicts. <snip> > On the argument of significant features for 7.5: > > Win32 Native > PITR Stupid question: whats PITR ? > Nested Transactions > Background Writer.... Background-Write = write-behind ? BTW: how stable is the current pgsql against powerfails or kill -9 ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------
Hello, This is probably better suited for something not on pgsql-advocacy. I will respond offlist. Sincerely, Joshua D. Drake Enrico Weigelt wrote: > * Joshua D. Drake <jd@commandprompt.com> wrote: > > <snip> > >>There is only one production and shipping replication that does not >>require triggers that I know of and that is ours (Command Prompt). >>It is also not a userland app but actually part of the PostgreSQL engine. > > Ah. Has pgsql to be patched for that or can it be simply dropped-in > like external (C) functions/procedures ? > > What about lazy replication (i.e. when some node is running but not > online for a while), masterless replication (all nodes are equal) > or journaling ? > My application/framework-level solves this, but > a) requires some special table layout (first attrs have to be inode+mtime), > b) not suited for high update-rates (relly too slow for that) > but it is already working quite stable for several years :) > > <snip> > >>Each solution has pro's and cons. Slony-I for example appears to be >>better when doing mass updates or deletes than Replicator. > > yeah, on subsequent mass-updates on just one host per table at certain time, > my stuff is also good, since it works w/ batching. but when multiple hosts > do heavy updates on the same table, it may run into conflicts. > > <snip> > >>On the argument of significant features for 7.5: >> >>Win32 Native >>PITR > > Stupid question: whats PITR ? > >>Nested Transactions >>Background Writer.... > > Background-Write = write-behind ? > > BTW: how stable is the current pgsql against powerfails or kill -9 ? > > > cu -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
> Where do the come in ? > Hast the postmaster to be patched and recompiled ? No. > Is there anywhere an overview about them ? http://gborg.postgresql.org/project/slony1/projdisplay.php > Are they publically available w/o fees ? Yes.
This probably has been discussed and is probably a very minor point, but consider how many more years we want to be able to use the <single digit>.<single digit> major release numbering. Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year), then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to 8.0 now, then we have up until 2023. Also we have 1 more chance to skip major number: 8.x -> 9.0. Imagine what features will there be in 9.0 that is ground-breaking enough. Because after that, we don't have any more major number to jump into without going into 2 digits. I personally don't see the major number as a very magical thing. Look at Linux for example. People still see 2.6 as very different/ahead compared to 2.4... -- dave
В Сбт, 05.06.2004, в 10:28, David Garamond пишет: > This probably has been discussed and is probably a very minor point, but > consider how many more years we want to be able to use the <single > digit>.<single digit> major release numbering. > > Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year), > then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to > 8.0 now, then we have up until 2023. > > Also we have 1 more chance to skip major number: 8.x -> 9.0. Imagine > what features will there be in 9.0 that is ground-breaking enough. > Because after that, we don't have any more major number to jump into > without going into 2 digits. What's the problem with 7.10? -- Markus Bertheau <twanger@bluetwanger.de>
Dave Page wrote: > From: David Garamond > Sent: Sat 6/5/2004 9:28 AM > Cc: postgresql advocacy; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ? > > Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year), > then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to > 8.0 now, then we have up until 2023. > > Hi Dave, > > I might be missing the point, but why can't we go to double figures? MS > Office has, HP-UX has, OS-X, Norton AV has, Madrake Linux has... Of course we can, I didn't say we can't. But double digits are sometimes undesirable because it can break some things. For example, a simple shell or Perl script might try to compare the version of two data directories by comparing the content of PG_VERSION stringwise. It then concludes that 7.10 is smaller than 7.4. Granted, the script itself is faulty, but since some other OS projects (like Ruby, with the same x.y.z numbering) do guarantee they never will have double digits in version number component than people might think the same too and thus the habit of stringwise version comparison continues. -- dave
David Garamond <lists@zara.6.isreserved.com> writes:
> Granted, the script itself is faulty, but since some other OS projects
> (like Ruby, with the same x.y.z numbering) do guarantee they never will
> have double digits in version number component
Oh? What's their plan for the release after 9.9.9?
In practice, non-broken bits of code don't make such an assumption,
as there have always been lots of projects with double-digit version
components. A quick grep for locally-installed packages finds
autoconf-2.53.tar.gz
binutils-2.10.1.tar.gz
bison-1.875.tar.gz
cvs-1.10.7.tar.gz
emacs-19.34b.tar.gz
expect-5.38.tar.gz
gcc-2.95.3.tar.gz
gettext-0.11.5.tar.gz
ghostscript-6.50.tar.gz
lesstif-0.89.9.tar.gz
lsof_4.47_W.tar.gz
make-3.79.1.tar.gz
mysql-3.23.29a-gamma.tar.gz
netcat-1.10.tar.gz
ntp-4.0.99k.tar.gz
procmail-3.22.tar.gz
sendmail.8.12.11.tar.gz
tar-1.13.tar.gz
IMHO trying to avoid double-digit component numbers is just silly.
regards, tom lane
Tom Lane wrote: >>Granted, the script itself is faulty, but since some other OS projects >>(like Ruby, with the same x.y.z numbering) do guarantee they never will >>have double digits in version number component > > Oh? What's their plan for the release after 9.9.9? As for Ruby, it probably won't expect > 9.9.9 in any foreseeable future. It takes +- 10 years to get to 1.8.1. Same with Python. But Perl will have 5.10.0. -- dave
From: David Garamond
Sent: Sat 6/5/2004 9:28 AM
Cc: postgresql advocacy; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Sent: Sat 6/5/2004 9:28 AM
Cc: postgresql advocacy; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to
8.0 now, then we have up until 2023.
Hi Dave,
I might be missing the point, but why can't we go to double figures? MS Office has, HP-UX has, OS-X, Norton AV has, Madrake Linux has...
Regards, Dave
"David Garamond" <lists@zara.6.isreserved.com> wrote: > Tom Lane wrote: > > Oh? What's their plan for the release after 9.9.9? > > As for Ruby, it probably won't expect > 9.9.9 in any foreseeable future. > It takes +- 10 years to get to 1.8.1. Same with Python. But Perl will > have 5.10.0. > You cannot seriously propose that the version number in itself should prevent a 10th bugfix on some branch just to satisfy the possible existence of an incorrect version number parser somewhere? > I personally don't see the major number as a very magical thing. Look at > Linux for example. People still see 2.6 as very different/ahead compared > to 2.4... > IMHO a discussion concerning rules controlling when and why things should be major versus minor releases is needed rather than invalidating the significance of major/minor/bugfix altogether. What you propose is very close to suggesting one single number ranging from 001 to 999. I don't think that will meet much sympathy either. Kind regards, Thomas Hallgren "David Garamond" <lists@zara.6.isreserved.com> wrote in message news:40C2BCEC.4040104@zara.6.isreserved.com... > Tom Lane wrote: > >>Granted, the script itself is faulty, but since some other OS projects > >>(like Ruby, with the same x.y.z numbering) do guarantee they never will > >>have double digits in version number component > > > > -- > dave > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >