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

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

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

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

Mike Mascari <mascarm@mascari.com> writes:

> 1) PITR
> 2) Distributed Tx
> 3) Replication
> 4) Nested Tx
> 5) PL/SQL Exception Handling

Of these PITR seems *by far* the most important. It makes the difference
between an enterprise-class database capable of running 24x7 with disaster
recovery plans, and a lesser beast that needs to be shut down for cold backups
periodically.

Features like Nested Transactions and Exception Handling are "would be nice"
features. Especially for pre-existing code-bases. But for new projects they're
not things that make the difference between measuring up and not.

Besides, Oracle 8 had Replication the way Mysql has transactions... It a
recently bolted-on addition that only worked in limited cases until a few
rewrites later.

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.

-- 
greg

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

I don't call porting Postgres to run well on something like 40% of the 
world's servers (or whatever it is) "just another port".

It could conveivably double Postgres's target audience, could attract 
heaps of new users, new developers, new companies and put us in a better 
position to compete with MySQL.

I think it's actually a necessary port to keep the project alive in the 
long term.

Chris

Christopher Kings-Lynne wrote:

>> 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.
>
> I don't call porting Postgres to run well on something like 40% of the 
> world's servers (or whatever it is) "just another port".
>
> It could conveivably double Postgres's target audience, could attract 
> heaps of new users, new developers, new companies and put us in a 
> better position to compete with MySQL.
>
> I think it's actually a necessary port to keep the project alive in 
> the long term.

Absolutely!  In addition, even if you don't consider win32 a platform to 
run production databases on, the win32 port will help developers who 
work from windows boxes, which is the certainly the most widely used 
desktop environment.  My former company would have loved the win32 port 
for exactly this reason, even though most of our servers were FreeBSD / 
Linux.

Matthew T. O'Connor writes:

> Absolutely!  In addition, even if you don't consider win32 a platform to
> run production databases on, the win32 port will help developers who
> work from windows boxes, which is the certainly the most widely used
> desktop environment.

At the risk of stating the obvious: Cygwin is your friend in exactly this
case.

-- 
Peter Eisentraut   peter_e@gmx.net

"Matthew T. O'Connor" <matthew@zeut.net> writes:

> > I don't call porting Postgres to run well on something like 40% of the
> > world's servers (or whatever it is) "just another port".
> >
> > It could conveivably double Postgres's target audience, could attract heaps
> > of new users, new developers, new companies and put us in a better position
> > to compete with MySQL.

That's a misleading extrapolation. If people wanted to run an open source
database they could just as easily run a Solaris, Linux, or BSD server to run
it on anyways. I assure you 40% of the worlds servers will not switch from
MSSQL to Postgres the day the win32 port comes out...

The reality is it just doesn't happen that way. Postgres isn't the first major
unixy software to get ported to windows. Emacs, Gcc, Mozilla, Gimp, even X all
have windows ports. And they're not dead ports either, they have significant
user-bases. But they don't make much of a dent compared to the much larger
entrenched Unix user-base and they don't change the nature of the development
much.

> Absolutely!  In addition, even if you don't consider win32 a platform to run
> production databases on, the win32 port will help developers who work from
> windows boxes, which is the certainly the most widely used desktop environment.
> My former company would have loved the win32 port for exactly this reason, even
> though most of our servers were FreeBSD / Linux.

Oh sure, it'll be useful. But it doesn't make the difference between different
classes of software. It'll still the same Postgres with the same set of things
it's capable of handling once you get it running. 

If you need 24x7, scalability to n terabytes or x transactions/s, guaranteed
data integrity in the face of various failures, none of the checklist items
you'll be looking for will be win32 support. PITR will probably be a factor in
meeting any of those requirements.

In any case, my post was mostly a troll, there's not really much point in
arguing with it. They're all useful features and I hope they're all in the
next version of postgres, whatever version number it's given :)

-- 
greg

--- Christopher Kings-Lynne <chriskl@familyhealth.com.au> wrote:
> 
> I don't call porting Postgres to run well on something like 40% of the 
> world's servers (or whatever it is) "just another port".

Statistics is a tricky thing. IMHO, there are plenty of things that are much
more important than win32 port.






__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Matthew T. O'Connor wrote:

> Christopher Kings-Lynne wrote:
>
>>> 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.
>>
>>
>> I don't call porting Postgres to run well on something like 40% of 
>> the world's servers (or whatever it is) "just another port".
>>
>> It could conveivably double Postgres's target audience, could attract 
>> heaps of new users, new developers, new companies and put us in a 
>> better position to compete with MySQL.
>>
>> I think it's actually a necessary port to keep the project alive in 
>> the long term.
>
>
> Absolutely!  In addition, even if you don't consider win32 a platform 
> to run production databases on, the win32 port will help developers 
> who work from windows boxes, which is the certainly the most widely 
> used desktop environment.  My former company would have loved the 
> win32 port for exactly this reason, even though most of our servers 
> were FreeBSD / Linux.


And my former company produced software that ran on Windows and *nix. We 
would have loved to be able to ship PostgreSQL as our reference 
database, but could not because there was no native Windows port.

We've been over this ground before. It might not be important to some 
people but it is important for a hell of a lot of others.

cheers

andrew

> 
> 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... 
Good point. To me the best argument against so far. 
> 
> Could be wrong, though...
> 
> Mike Mascari
> mascarm@mascari.com
> 
> 
Regards, Christoph 

Le Mardi 18 Novembre 2003 06:21, Greg Stark a écrit :
> 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.

Dear Greg,

In your opinion, why did MySQL capture so many users quickly?

Is it because MySQL offers a nice and powerful solution? No, on the converse,
everyone knows that MySQL is not a reliable database. To some extent, MySQL
is not really ACID compliant. It cannot parse large queries with LEFT and
RIGHT joins. It does not offer reliable ODBC. And it does not evolve very
quickly. it does not support Unicode. There are no server-side languages.
etc...

So why did MySQL succeed? In my opinion, because Php and MySQL were both
available on Apache servers (GNU/Linux) and on home stations (Win32). Simple
as that.

This kind of cross-needs-effect is called a ***portfolio effect***. The
portfolio effect is the ***central marketing strategy*** of Microsoft when
releasing OS and Office suites together.

Because your Grand-mother owns a Win 95 station, she sends you files under
PowerPoint 95, in turn you invest in Office 2000 and send Excel 2000 files to
your brother, who in turn invests in Office XP and prints Word XP documents.
[<---Future readers in 200 years: all these names used tp be trademarks from
Microsoft in a time when a few people tried to lock-up ideas.-->].

And you end up with everyone upgrading Office and Windows. Now, without being
pretentious, I would like to remind this simple idea:

***Who lives by the sward, dies by the sward***

If we apply the same strategy as Microsoft or MySQL, PostgreSQL can conquer
the whole market. Not 1% like today, but 60% or more like Apache. Because we
are a community.

If you do not believe reaching 60% of market shares is possible, let us assume
that a PostgreSQL Win32 native port is available in 6 months. Immediately,
the following bundles would appear:

- PostgreSQL + PhpPgAdmin + pgAdmin -> a potential of 1 million users
- Apache2.0 + Php5 + PostgreSQL -> a potential of 5 million users
- OpenOffice + PostgreSQL -> a potential of 10 million users
- Some MS Access replacement -> a potential of 2 million users
- there are many others...

For me, this makes 60% of the market at least.
A 1% to 60% is not a small difference, it is a real gap.

Best regards,
Jean-Michel

Uz.ytkownik Jean-Michel POURE napisa?:

> 
> For me, this makes 60% of the market at least.
> A 1% to 60% is not a small difference, it is a real gap.
> 

Don't forget that success isn't always connected with technical things 
(very good example is MySQL :-)) - PostgreSQL needs a good marketing, 
clear strategy and identity. But for sure Win32 port will be a huge step.

There are other databases which have Win32 native version and aren't so 
popular (like Firebird...)... So my proposition to PostgreSQL's team is 
to think also about SMI -> Strategy Marketing Identity...

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

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