Not 7.5, but 8.0 ?

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

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

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

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

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

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

"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

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: Monday, November 17, 2003 10:04 PM
To: Matthew T. O'Connor
Cc: Christopher Kings-Lynne; Greg Stark; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

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.

Yes, but how friendly is it?

Cygwin requires a license for commercial use.

Dann Corbit writes:

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

Yes, but how friendly is it?

What are you asking here? Is it easy to install and use? Yes.

Cygwin requires a license for commercial use.

No, it does not.

--
Peter Eisentraut peter_e@gmx.net

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

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: Monday, November 17, 2003 10:34 PM
To: Dann Corbit
Cc: Matthew T. O'Connor; Christopher Kings-Lynne; Greg Stark;
PostgreSQL Development
Subject: RE: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

Dann Corbit writes:

At the risk of stating the obvious: Cygwin is your friend

in exactly

this case.

Yes, but how friendly is it?

What are you asking here? Is it easy to install and use? Yes.

You brought it up.

Cygwin requires a license for commercial use.

No, it does not.

Really?

What's this then?
http://www.cygwin.com/licensing.html
http://www.redhat.com/software/cygwin/

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

-----Original Message-----
From: ow [mailto:oneway_111@yahoo.com]
Sent: Monday, November 17, 2003 10:39 PM
To: Christopher Kings-Lynne; Greg Stark
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

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

Which feature is requested more than that?

If you consider the possibility of embedded PostgreSQL, which OS covers
the most desktops in the world, by several orders of magnitude?

Of the following (which includes every significant DBMS in terms of
market share), which did not consider a native Windows port to be
important:
SQL*Sever (all right, we can discount this one...)
DB/2
Oracle
MySQL
Sybase
Informix

(Answer: none of them)

Maybe they were all mistaken.

At the company where I work (CONNX Solutions Inc.) we spent a giant pile
of money writing a native port of PostgreSQL 7.1.3 because there were no
viable alternatives for what we wanted to do. We would have saved many
tens of thousands of dollars if one were available. Now, I imagine
other companies might also have their interest piqued if a native port
should suddenly appear.

By the (non-existant) powers vested in me I hereby designate this as
"rehash old and fruitless arguments" week.

cheers

andrew

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

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

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: 17 November 2003 23:31
To: Josh Berkus
Cc: pgsql-hackers@postgresql.org; pgsql-advocacy@postgresql.org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

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.

Least interesting to many user perhaps, but lost of them seen to think
that it's important for expanding our userbase:
http://www.postgresql.org/survey.php?View=1&amp;SurveyID=9

That can't be a bad thing.

Regards, Dave.

Dann Corbit writes:

Cygwin requires a license for commercial use.

No, it does not.

Really?

What's this then?
http://www.cygwin.com/licensing.html

The Cygwin license, the GPL, specifically says:

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, ...

So "commercial use" is clearly allowed.

--
Peter Eisentraut peter_e@gmx.net

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

Dave Page writes:

Least interesting to many user perhaps, but lost of them seen to think
that it's important for expanding our userbase:
http://www.postgresql.org/survey.php?View=1&amp;SurveyID=9

That survey is a bit like asking television viewers, "What do you think
would attract the most new television viewers?"

33% -- better entertainment

That does not say that better entertainment will attract new viewers, just
that the existing viewers think that. Most nonviewers might in fact be
perfectly content with their way of living.

--
Peter Eisentraut peter_e@gmx.net

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: 18 November 2003 09:23
To: Dave Page
Cc: Josh Berkus; pgsql-hackers@postgresql.org;
pgsql-advocacy@postgresql.org
Subject: RE: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

Dave Page writes:

Least interesting to many user perhaps, but lost of them

seen to think

that it's important for expanding our userbase:
http://www.postgresql.org/survey.php?View=1&amp;SurveyID=9

That survey is a bit like asking television viewers, "What do
you think would attract the most new television viewers?"

33% -- better entertainment

That does not say that better entertainment will attract new
viewers, just that the existing viewers think that. Most
nonviewers might in fact be perfectly content with their way
of living.

Right, but not having the luxury of time travel (wasn't that removed in
Postgres95? ;-) ) we can only go by what the majority think. We won't
know if it's actually right unless we try it.

We could run a survey saying 'would you use PostgreSQL on win32', but
the chances are that the vast majority of potential win32 users would
not visit the site to answer that until it became widely know that we do
support win32, by which time of course it's all a bit moot.

Unless of course, you have other stats that prove that win32 support is
uninteresting to most people and potential users?

Regards, Dave.

Dave Page wrote:

Right, but not having the luxury of time travel (wasn't that removed in
Postgres95? ;-) ) we can only go by what the majority think. We won't
know if it's actually right unless we try it.

We could run a survey saying 'would you use PostgreSQL on win32', but
the chances are that the vast majority of potential win32 users would
not visit the site to answer that until it became widely know that we do
support win32, by which time of course it's all a bit moot.

Unless of course, you have other stats that prove that win32 support is
uninteresting to most people and potential users?

Regards, Dave.

I'm sorry if I'm being alow here - is there any problem with running a
production server on cygwin's postgresql? Is the cygwin port of lesser
quality, or otherwise inferior?

I understand that the installation is a bit awkward for cygwin. I
somehow don't see that as too much of a problem. As for usage - RedHat
guidelines clearly state that OSI approved licensed programs will not be
considered by them derived work of the cygwin dll (the one who's GPLness
caused the original discussion). This, aside from the question of
whether they have any claim on Posix utilities anyhow, or whether a
commercial application using PGSQL should be considered derived work of
it, mean to me that there is no problem in distributing a commercial app
that uses Cygwin PostgreSQL.

Shachar

--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/

Shachar Shemesh wrote:

I'm sorry if I'm being alow here

alow->slow

Just wanted to avoid confusion.

--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/

U�ytkownik Shachar Shemesh napisa�:

Dave Page wrote:

Right, but not having the luxury of time travel (wasn't that removed in
Postgres95? ;-) ) we can only go by what the majority think. We won't
know if it's actually right unless we try it.

We could run a survey saying 'would you use PostgreSQL on win32', but
the chances are that the vast majority of potential win32 users would
not visit the site to answer that until it became widely know that we do
support win32, by which time of course it's all a bit moot.

Unless of course, you have other stats that prove that win32 support is
uninteresting to most people and potential users?

Regards, Dave.

I'm sorry if I'm being alow here - is there any problem with running a
production server on cygwin's postgresql? Is the cygwin port of lesser
quality, or otherwise inferior?

Performance, performance, perfomance... and perfomance... it is (almost)
always worse perfomance when we emulate something... and using Cygwin we
are emulating U*nix...

I'm sorry if I'm being alow here - is there any problem with running a
production server on cygwin's postgresql? Is the cygwin port of lesser
quality, or otherwise inferior?

Performance, performance, perfomance... and perfomance... it is (almost)
always worse perfomance when we emulate something... and using Cygwin we
are emulating U*nix...

Absolutely. The DB throughput available to our application with postgresql
under cygwin is about 1/3 of what we get under Linux with a similar spec
machine/config.

That, and, more importantly, the odd spurious cygipc lock up, precludes our
use of postgresql/cygwin in a production setting. And not having postgresql
available on all our target platforms (which includes Windows) precludes the
use of it at all, as we desire a single DB solution. I don't imagine we are
the only ones in this situation (and to all those who see a Windows port as
"uninteresting", please keep this in mind).

Hopefully, we can change this situation soon...

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli wrote:

I'm sorry if I'm being alow here - is there any problem with running a
production server on cygwin's postgresql? Is the cygwin port of lesser
quality, or otherwise inferior?

Performance, performance, perfomance... and perfomance... it is (almost)
always worse perfomance when we emulate something... and using Cygwin we
are emulating U*nix...

Absolutely. The DB throughput available to our application with postgresql
under cygwin is about 1/3 of what we get under Linux with a similar spec
machine/config.

That, and, more importantly, the odd spurious cygipc lock up, precludes our
use of postgresql/cygwin in a production setting. And not having postgresql
available on all our target platforms (which includes Windows) precludes the
use of it at all, as we desire a single DB solution. I don't imagine we are
the only ones in this situation (and to all those who see a Windows port as
"uninteresting", please keep this in mind).

You are far from alone. And there's one other factor: most large
enterprises have quite strict policies about what can be installed on
their data center servers. Getting Cygwin past those policies would
often be difficult. That factor alone was enough to make my product
manager rule Postgres out as a solution that we would bundle with our
software.

Hopefully, we can change this situation soon...

Right.

Here's the situation as I see it:
. there have been lots of requests for a native Win32 port
. this is important to some people and not important to others
. the decision has long ago been made to do it, and some work has been
done, and more is being done

Isn't it time to move on?

As for release numbering, ISTM that is not fundamentally very important.
At my former company we had code names for branches and decided release
names/numbers near release time in accordance with marketing
requirements. Let's not get hung up on nominalism. A release number is
just a tag and we can call it whatever seems good at the time.

cheers

andrew

Uz.ytkownik Andrew Dunstan napisa?:

Claudio Natoli wrote:
As for release numbering, ISTM that is not fundamentally very important.
At my former company we had code names for branches and decided release
names/numbers near release time in accordance with marketing
requirements. Let's not get hung up on nominalism. A release number is
just a tag and we can call it whatever seems good at the time.

Maybe it's a good time to think about PostgreSQL's marketing strategy &
identity. Maybe this great DBMS should be changed in all areas - not
only in technical related fields ?

ML

Claudio Natoli wrote:

Claudio Natoli wrote nothing of the sort :-P

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

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

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

Andrew Dunstan wrote:

Here's the situation as I see it:
. there have been lots of requests for a native Win32 port
. this is important to some people and not important to others
. the decision has long ago been made to do it, and some work
has been done, and more is being done

Isn't it time to move on?

No arguments here. As soon as the fork/exec changes are in place, count me
in!

Speaking of which, any ETA on this? Bruce? If anyone from core can indicate
how they'd like this architected (from the perspective of code
rearrangement), I'm willing to have a crack at this.

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

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

Claudio Natoli wrote:

Andrew Dunstan wrote:

Here's the situation as I see it:
. there have been lots of requests for a native Win32 port
. this is important to some people and not important to others
. the decision has long ago been made to do it, and some work
has been done, and more is being done

Isn't it time to move on?

No arguments here. As soon as the fork/exec changes are in place, count me
in!

It doesn't matter really --- I am working on the win32 port, and will
make sure it is done and I will make sure it is done so it doesn't
uglify our code.

Speaking of which, any ETA on this? Bruce? If anyone from core can indicate
how they'd like this architected (from the perspective of code
rearrangement), I'm willing to have a crack at this.

http://momjian.postgresql.org/main/writings/pgsql/win32.html

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

Speaking of which, any ETA on this? Bruce? If anyone from

core can indicate

how they'd like this architected (from the perspective of code
rearrangement), I'm willing to have a crack at this.

http://momjian.postgresql.org/main/writings/pgsql/win32.html

No, sorry, I should have been clearer. Here I was referring specifically to
the fork/exec parts, not the entire porting effort.

[I remembered a post of yours of a few weeks ago, mentioning that the
fork/exec bits might be in in "a few weeks"; something along the lines of
that it was taking you a while not due to "issues", but simply a lack of
time (can't find the exact message; might be mis-remembering)]

Probably something you are close to completing, but if not, and you can
describe how you'd prefer any rearrangement, I'm happy taking this one.

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli wrote:

Bruce Momjian wrote:

Speaking of which, any ETA on this? Bruce? If anyone from

core can indicate

how they'd like this architected (from the perspective of code
rearrangement), I'm willing to have a crack at this.

http://momjian.postgresql.org/main/writings/pgsql/win32.html

No, sorry, I should have been clearer. Here I was referring specifically to
the fork/exec parts, not the entire porting effort.

[I remembered a post of yours of a few weeks ago, mentioning that the
fork/exec bits might be in in "a few weeks"; something along the lines of
that it was taking you a while not due to "issues", but simply a lack of
time (can't find the exact message; might be mis-remembering)]

Probably something you are close to completing, but if not, and you can
describe how you'd prefer any rearrangement, I'm happy taking this one.

I am ready to work with anyone to make fork/exec happen. It requires we
find out what globals are being set by the postmaster, and have the
child run those same routines. I can show you examples of what I have
done and walk you through areas that need work. If you look at the
EXEC_BACKEND defines in CVS, you can see what I have done so far. We
need to have EXEC_BACKEND working on Unix first, then we can add the
CreateProcess call on Win32, so all this can be done on Unix first.

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

I am ready to work with anyone to make fork/exec happen. It requires we

find out what globals are being set by the postmaster, and have the
child run those same routines. I can show you examples of what I have
done and walk you through areas that need work. If you look at the
EXEC_BACKEND defines in CVS, you can see what I have done so far. We
need to have EXEC_BACKEND working on Unix first, then we can add the
CreateProcess call on Win32, so all this can be done on Unix first.

How is EXEC_BACKEND going to be enabled? A configure option? A global
define?

cheers

andrew

--- Dann Corbit <DCorbit@connx.com> wrote:

Which feature is requested more than that?

Not sure how often features are requested and by whom. However, if you take a
look at the TODO list, you'll find plenty of stuff more important than win32
port.

Of the following (which includes every significant DBMS in terms of
market share), which did not consider a native Windows port to be
important:
SQL*Sever (all right, we can discount this one...)
DB/2
Oracle
MySQL
Sybase
Informix

Have *never* seen ppl running Oracle or Sybase on Windows. Not sure about DB/2
or Informix, never worked with them, but I'd suspect the picture is the same.
They may claim that they have win port but it's more of a marketing gimmick
than a useful feature that affects real, not hypothetical, users.

IMHO, core postgreSql development should not be sacrificed for the sake of
win32 port.

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

On Tue, 18 Nov 2003, ow wrote:

Have *never* seen ppl running Oracle or Sybase on Windows.

I can't speak for Oracle, but Sybase on Windows is definitely a real
thing. If you have to deal with developing for their iAnywhere product (a
remote replication solution for PocketPC applications), Windows is the
first class citizen for the database and Unix is definitely second class
(can attest to that from first hand experience).

We had trouble convincing them that we wanted to run with Postgres as the
data repository under Unix. A native win32 port would have helped us out.

-rocco

ow wrote:

Have *never* seen ppl running Oracle or Sybase on Windows. Not sure about DB/2
or Informix, never worked with them, but I'd suspect the picture is the same.

Then you need to get out more. I have seen Oracle, Sybase, DB2 (and
probably Informix, I forget) all running on Windows in a number of large
enterprise data centers.

They may claim that they have win port but it's more of a marketing gimmick
than a useful feature that affects real, not hypothetical, users.

IMHO, core postgreSql development should not be sacrificed for the sake of
win32 port.

Nobody is sacrificing anything. As usual, people are working on the
things that they want to work on.

A Win32 port is clearly not important *to*you*. It is to others, and
it's going to happen. You might dislike the decision but you need to get
over it. If you feel other things are more important feel free to
contribute to that work.

I am sure the core team will make sure that the Win32 work does not
break or degrade the product on Unix, so why the heck should you even
care? I'm not a big Windows fan either, but I also live in the real
world. I suspect that goes for most of us who want to see this work done.

I still don't know why we are even having this discussion.

andrew

--- Rocco Altier <roccoa@routescape.com> wrote:

On Tue, 18 Nov 2003, ow wrote:

Have *never* seen ppl running Oracle or Sybase on Windows.

I can't speak for Oracle, but Sybase on Windows is definitely a real
thing. If you have to deal with developing for their iAnywhere product

iAnywhere is a completely separate product and is *not* a port of Sybase ASE
(core db server). IIRC, iAnywhere runs only on Windows, well, maybe they ported
it to Linux by now.

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

Marek,

Maybe it's a good time to think about PostgreSQL's marketing strategy &
identity. Maybe this great DBMS should be changed in all areas - not
only in technical related fields ?

If your interest is "marketing" PostgreSQL, please join the Advocacy list.

That goes for anyone on this list who is interested in PostgreSQL Advocacy
from whatever perspective, including if you want us to stop doing it. It's
an open list ... come join!

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tue, Nov 18, 2003 at 08:39:29AM -0800, ow wrote:

Have *never* seen ppl running Oracle or Sybase on Windows.

I _have_ certainly seen plenty of people running Oracle on Windows.
They weren't necessarily happy, of course, but people do it all the
time.

As for Sybase, you don't see that because Sybase on Windows was, for
a long time, SQL Server.

I do not have any real personal jones to get Postgres on Windows, but
that does not make it any less valuable to those who want it, and are
apparently doing the work to provide it. From my point of view, we
should just encourage the project that is already in motion.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

Peter,

Well, based on the feedback we're getting from the 7.4 release, the #1 issue
for non-postgresql users who are interested enough to post to message boards
is "Where is the Windows Port?" This gets mentioned roughly 10 times as
often as any other potential feature.

So the Windows port is a mostly question of what matters to people who
*aren't* using PostgreSQL currently, assuming we want our community to grow
(and I think we do, since communities which don't grow die). For many if
not most of our current users it doesn't matter as much, becuase if it did
they wouldn't be using PostgreSQL.

But it affects current users too. I had to pass on two potential contracts
in 2003 because the use of Windows servers was stipulated. The second of
these I was really put out about since it was a scheduling application,
something that both I and PostgreSQL excel at were it not on Windows. You
probably aren't faced with this issue as much in Germany, but it happens
often to us folks in the US & Canada.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tue, Nov 18, 2003 at 09:24:25AM -0800, Josh Berkus wrote:

Well, based on the feedback we're getting from the 7.4 release, the #1 issue
for non-postgresql users who are interested enough to post to message boards
is "Where is the Windows Port?" This gets mentioned roughly 10 times as

This is also, by the way, a reason not to say, "_X_ is planned for
the next release," unless there is acutal working code kicking
around. Lots of people saw the remarks (I am among the guilty for
repeating it, I think) that a Windows port seemed to be planned for
7.4. So some of us were guilty of flogging vapourware, I'm afraid.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

On Tue, Nov 18, 2003 at 12:18:51PM -0500, Andrew Sullivan wrote:

On Tue, Nov 18, 2003 at 08:39:29AM -0800, ow wrote:

Have *never* seen ppl running Oracle or Sybase on Windows.

I _have_ certainly seen plenty of people running Oracle on Windows.
They weren't necessarily happy, of course, but people do it all the
time.

As for Sybase, you don't see that because Sybase on Windows was, for
a long time, SQL Server.

Not exaclty. Sybase 4.21 = MS SQL server 4.21. But then they ended their
relationship (much like MS and IBM did over OS/2). This was somewhere
around the mid 90's. Since then Sybase has renamed their enterprise
product to Adaptive Server Enterprise, and versions 10, 11, 11.5 and
beyond have always been available on windows.

A few years after they split up with Microsoft, they bought the product
SQL Anywhere (forgot the firm they bought it from). It took them a few
years to make this product 100% SQL compatible with ASE. This product was
ported to some Unix platforms around that time too.

--
__________________________________________________
"Nothing is as subjective as reality"
Reinoud van Leeuwen reinoud.v@n.leeuwen.net
http://www.xs4all.nl/~reinoud
__________________________________________________

A long time ago, in a galaxy far, far away, oneway_111@yahoo.com (ow) wrote:

Have *never* seen ppl running Oracle or Sybase on Windows.

I haven't seen Sybase on Windows (only barely have seen it anywhere,
fitting with the comment made that it hides in the lucrative financial
industry); I _have_ seen Oracle deployed on Windows NT. (I was once
involved with a deployment on Novell Netware, which is _really_ odd,
as platforms go :-).)

That we don't see these things a lot may mean that we are seeing
somewhat "ghettoized" areas of the computer industry. I doubt Sybase
'does Windows' terribly much, but just because I don't see it doesn't
mean it doesn't exist.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('aa454','freenet.carleton.ca').
http://cbbrowne.com/info/linuxdistributions.html
Subject: SETI@home
Or perhaps a better subject title would be, "Watching paint dry, but
geekier."
-- Brian Menyuk

Hi

You
probably aren't faced with this issue as much in Germany, but it

happens

often to us folks in the US & Canada.

About half of the mails that I get are Cygwin-Windows related. So I
consider it of great interest in Germany.

Regards
Conni

-----Original Message-----
From: ow [mailto:oneway_111@yahoo.com]
Sent: Tuesday, November 18, 2003 8:39 AM
To: Dann Corbit; Christopher Kings-Lynne; Greg Stark
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

--- Dann Corbit <DCorbit@connx.com> wrote:

Which feature is requested more than that?

Not sure how often features are requested and by whom.
However, if you take a look at the TODO list, you'll find
plenty of stuff more important than win32 port.

Of the following (which includes every significant DBMS in terms of
market share), which did not consider a native Windows port to be
important:
SQL*Sever (all right, we can discount this one...)
DB/2
Oracle
MySQL
Sybase
Informix

Have *never* seen ppl running Oracle or Sybase on Windows.
Not sure about DB/2 or Informix, never worked with them, but
I'd suspect the picture is the same. They may claim that they
have win port but it's more of a marketing gimmick than a
useful feature that affects real, not hypothetical, users.

I have all of the above database systems installed on the Windows 2000
machine I am typing this message from.
DB/2 7.1
Oracle 8.1.7 and 9.2.0.5
MySQL 4.0.12
Sybase Adaptive Server 12.0
Informix Dynamic Server 9.2
(Also SapDB, Firebird server, SQL*Server, and several others that are
not running right now)

I just use them for development on this machine, but we have literally
thousands of customers with those database systems installed on Win32
and used in production.

IMHO, core PostgreSQL development should not be sacrificed
for the sake of win32 port.

A typical window-phobic. Thankfully, cooler heads will prevail.

--- Dann Corbit <DCorbit@connx.com> wrote:

I have all of the above database systems installed on the Windows 2000
machine I am typing this message from.
DB/2 7.1
Oracle 8.1.7 and 9.2.0.5
MySQL 4.0.12
Sybase Adaptive Server 12.0
Informix Dynamic Server 9.2
(Also SapDB, Firebird server, SQL*Server, and several others that are
not running right now)

I'd say your environment is somewhat unique.

A typical window-phobic.

Not really. I simply think there are more pressing issues than win32 port.

Peace

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

-----Original Message-----
From: ow [mailto:oneway_111@yahoo.com]
Sent: Tuesday, November 18, 2003 11:23 AM
To: Dann Corbit; Christopher Kings-Lynne; Greg Stark
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

--- Dann Corbit <DCorbit@connx.com> wrote:

I have all of the above database systems installed on the

Windows 2000

machine I am typing this message from. DB/2 7.1
Oracle 8.1.7 and 9.2.0.5
MySQL 4.0.12
Sybase Adaptive Server 12.0
Informix Dynamic Server 9.2
(Also SapDB, Firebird server, SQL*Server, and several

others that are

not running right now)

I'd say your environment is somewhat unique.

No argument there.

A typical window-phobic.

Not really. I simply think there are more pressing issues
than win32 port.

Peace

I suppose I get rabid about it because I will benefit in a stupendous
way when it becomes available. Hence, I see that area of development
from different colored lenses than you do.

Andrew Dunstan wrote:

Bruce Momjian wrote:

I am ready to work with anyone to make fork/exec happen. It requires we

find out what globals are being set by the postmaster, and have the
child run those same routines. I can show you examples of what I have
done and walk you through areas that need work. If you look at the
EXEC_BACKEND defines in CVS, you can see what I have done so far. We
need to have EXEC_BACKEND working on Unix first, then we can add the
CreateProcess call on Win32, so all this can be done on Unix first.

How is EXEC_BACKEND going to be enabled? A configure option? A global
define?

We will use it for testing to make sure Unix can work with exec(), then
we add CreateProcess and make EXEC_BACKEND defined for that platform.

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

Least interesting to many user perhaps, but lost of them

seen to think

that it's important for expanding our userbase:
http://www.postgresql.org/survey.php?View=1&amp;SurveyID=9

That does not say that better entertainment will attract new
viewers, just that the existing viewers think that.

Perhaps more compelling is this survey, which shows that 21% of the users
are on actually the win32/cygwin platform now & hence are not enjoying the
performance or ease of installation that the other 79% of us get.

http://www.postgresql.org/survey.php?View=1&amp;SurveyID=11

-Nick

"Dann Corbit" <DCorbit@connx.com> writes:

I have all of the above database systems installed on the Windows 2000
machine I am typing this message from. DB/2 7.1
Oracle 8.1.7 and 9.2.0.5
MySQL 4.0.12
Sybase Adaptive Server 12.0
Informix Dynamic Server 9.2
(Also SapDB, Firebird server, SQL*Server, and several others that are
not running right now)

I suppose I get rabid about it because I will benefit in a stupendous
way when it becomes available. Hence, I see that area of development
from different colored lenses than you do.

My rhetoric kind of got out of hand, but in fact I'm sure a win32 port would
be useful. And I'm sure there are particular people for whom it would be very
useful.

But my point was that it doesn't really change the nature of what you can or
can't do with Postgres. If you want to run Postgres it just means you have to
set up a Linux or BSD box first and then you get the same feature set as you
will when the port is done. Having a win32 port just means it's more
convenient.

Whereas PITR makes the difference between being able to meet some technical
requirements or not. Most importantly, it makes the difference between being
fully 24x7 capable and not.

By way of illustration, *all* of the above listed databases (with the
exception of MySQL of course) had hot backups and PITR *long* before they had
windows ports.

In any case I regret trolling. Mea Culpa. The whole discussion is pointless.
This isn't how free software advances. Developers will work on what captures
their fancy and the users don't get to vote unless they pay the bills or
contribute the code themselves. :)

--
greg

Le Mardi 18 Novembre 2003 20:22, ow a écrit :

Not really. I simply think there are more pressing issues than win32 port.

Dear friends,

Porting to Win32 can multiply:
- direct users (i.e. developers) by a factor of two or three,
- indirect users by a larger factor, provided that major projects include
PostgreSQL in their offer.

PostgreSQL is a potential candidate for integration in OpenOffice, PHP bundles
and several other projects. This is not the case of Firebird or MySQL which
are not mature enough and do not cover all needs like PostgreSQL does.

PostgreSQL Win32 users can account in millions of people, not hundred
thousands like today.

OK, now, some of us will complain that Win32 is not needed at a time when the
Debian Synaptic graphical installer gives access to 13.748 packages. Win32
sounds like an "old Atari game station". Agreed. On the long-run, everyone
will leave Win32, even my grand-mother.

But, on the converse, porting PostgreSQL to Windows "today" should be
considered with care, because Win32 is the last "component" needed to reach a
portfolio effect.

[or to make a comparision in the "Risk" strategy game, when you have all
countries in a continent, you win the continent].

Presently, PostgreSQL can be viewed as a large range of products and
solutions. But this "range" only needs the Win32 port to become a complete
portfolio. A portfolio effect is reached when you always answer questions
with "Yes" or "All".

Do you do this or do that?
Answer A: yes, we do them All.
Answer B: yes, we do them All.
Answer C: yes, we do them All.
= portfolio effect
...

You wake-up and suddenly PostgreSQL becomes the next Office-suite in the
domain of databases. This attracks more developers and everyone is happy with
business.

Cheers,
Jean-Michel

Jean-Michel POURE wrote:

OK, now, some of us will complain that Win32 is not needed at a time when the
Debian Synaptic graphical installer gives access to 13.748 packages. Win32
sounds like an "old Atari game station". Agreed. On the long-run, everyone
will leave Win32, even my grand-mother.

Well, jokes and rants aside, win32 port is on high priority.

The whole debate started on advocacy was 'Whether win32 port is killer-enough
feature?' and not 'Whether win32 port is required now?'

Win32 will happen. and we will revisit this debate when there is another release
with win32..:-)

Shridhar

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

* 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

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>

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

Regards, Dave

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

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