Обсуждение: have you seen this?
Robert Bernier wrote: > http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare.html "One of the co-authors (W.Peryt), after his presentation on databases, was asked by the Technical Board at its meeting held at CERN on December 7-th 2000 to prepare such a document." So it's probably not very applicable to the current releases of those three DBMSs. -Neil
I like the way it was put together. I wonder if it would be reasonable to ask these people, or whomever, to create an updated one. Robert Bernier Neil Conway wrote: > Robert Bernier wrote: > >> http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare.html > > > > "One of the co-authors (W.Peryt), after his presentation on databases, > was asked by the Technical Board at its meeting held at CERN on > December 7-th 2000 to prepare such a document." > > So it's probably not very applicable to the current releases of those > three DBMSs. > > -Neil > > > ---------------------------(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 >
>http://det-dbalice.if.pw.edu. pl/det-dbalice/ttraczyk/db_compare/db_compare.html I am not sure whether I misunderstand their section of "National characters support" or not. My understanding is that PostgreSQL supports 31 or so code sets for client when the server uses Unicode. Regards, CN
I think what is needed is a little more of a write up that describes their categories and how you arrive at what is considered "good". cnliou wrote: >>http://det-dbalice.if.pw.edu. >> >> >pl/det-dbalice/ttraczyk/db_compare/db_compare.html > >I am not sure whether I misunderstand their section of >"National characters support" or not. My understanding is >that PostgreSQL supports 31 or so code sets for client when >the server uses Unicode. > >Regards, > >CN > > >
El Sáb 22 May 2004 20:00, Robert Bernier escribió: > http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare. >html I don't know when they wrote this but...: Subqueries in FROM clause Possibility of using subquery (nested query) in FROM clause of SQL query. MySQL: No. Will be added in next versions. Oracle8: Yes. Postgres: No. The feature will be supported from version 7.1. When was 7.1 released? 2001? -- 10:05:01 up 9 days, 20:16, 1 user, load average: 0.60, 0.80, 0.80 ----------------------------------------------------------------- Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar' Centro de Telematica | DBA, Programador, Administrador Universidad Nacional del Litoral -----------------------------------------------------------------
Martin Marques wrote: > El Sáb 22 May 2004 20:00, Robert Bernier escribió: >> http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare. >>html > > I don't know when they wrote this but...: > > > Subqueries in FROM clause > > Possibility of using subquery (nested query) in FROM clause of SQL query. > > MySQL: > No. Will be added in next versions. > > Oracle8: > Yes. > > Postgres: > No. The feature will be supported from version 7.1. > > > When was 7.1 released? 2001? Yeah, and funny enough, it's still "to be" included in the next version of MySQL ... and what they have so far for 4.1 (in the 4.1.1 Alpha) is one implementation of subselects for the FROM clause and apparently another one for the WHERE clase (this is an assumption based on the fact that subselects support different language features if they are in the FROM clause or the WHERE clause). Fortunately I don't have to maintain any of that code. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Sat, 2004-05-22 at 19:00, Robert Bernier wrote: > > > http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare.html > Interesting write-up, too bad it is so out of date. Near as I can figure this seems to be discussing postgresql 7.0, maybe 7.1 ? Course would be a good starting point for a "grand database feature comparison" that folks have often talked about writing up. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Using this as a template, do we have the people in the advocacy that could generate an up to date version? Robert Treat wrote: >On Sat, 2004-05-22 at 19:00, Robert Bernier wrote: > > >>http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare.html >> >> >> > >Interesting write-up, too bad it is so out of date. Near as I can figure >this seems to be discussing postgresql 7.0, maybe 7.1 ? > >Course would be a good starting point for a "grand database feature >comparison" that folks have often talked about writing up. > >Robert Treat > >
Hi! Robert Treat wrote: >>http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare.html > > Interesting write-up, too bad it is so out of date. Near as I can figure > this seems to be discussing postgresql 7.0, maybe 7.1 ? > > Course would be a good starting point for a "grand database feature > comparison" that folks have often talked about writing up. While feature comparisons may work with people migrating from commercial RDBMSs, as they'll consider the feature/price ratio, this does not quite work with MySQL crowd. I was recently giving a small presentation on PostgreSQL on a Russian PHP conference and found out an interesting thing: no one there really cared about feature comparisons. I did a table with PostgreSQL features and the versions they appeared in. This did not go completely unnoticed, as the next lecture was about the new features of MySQL 4.1/5.0, but the people were not really interested and didn't ask questions. What's more interesting, no one really cared about PL/PHP as well. The meta-questions asked were: 1) The main *drawbacks* of PostgreSQL; 2) When does one need to use PostgreSQL; 3) The performance question. As the PostgreSQL advocacy group thinks that PHP programmers are among their *main* target audience, may I humbly suggest answering the questions that are asked instead of the ones that are not? The most successful (most quoted) advocacy articles I remember were the once from OpenACS (Why not MySQL?) and sql-info.de (MySQL gotchas). To make people look at PostgreSQL you should concentrate on why MySQL is *bad*, to create a sense of insecurity in its users. That is the propaganda that works.
Alexey, First off, I'm glad you posted this. Our advocacy thinking tends to be heavily US-dominated and I've wondered for a while how things are in your part of the world. > I was recently giving a small presentation on PostgreSQL on a Russian > PHP conference and found out an interesting thing: no one there really > cared about feature comparisons. I did a table with PostgreSQL features > and the versions they appeared in. This did not go completely unnoticed, > as the next lecture was about the new features of MySQL 4.1/5.0, but the > people were not really interested and didn't ask questions. Clayton Christensen has a facinating book called "The Inventor's Dillemma" about how business forces inevitably push companies to over-feature their own customer base. Certainly both MySQL and PostgreSQL already have more features than 85% of the PHP community has any interest in. > As the PostgreSQL advocacy group thinks that PHP programmers are among > their *main* target audience, may I humbly suggest answering the > questions that are asked instead of the ones that are not? Well, the first question I would ask *us* is whether or not PHP programmers *are* among our main targets for advocacy. Based on my experience at PHPCon, I would say that 80% of PHP coders would be well served by SQLite -- MySQL is more powerful than they need or want, let alone us. Not that I'm writing off the PHP community. Given PostgreSQL's powerful functions, views, and other in-database code, it makes a really dynamic pairing with a lightweight scripting language like PHP -- one which I've used to great effect. But I think that the target audience for this message is not necessarily existing PHP jockeys, but rather coders in client-side languages, and database designers used to Oracle and MSSQL, looking to move to the web. Overall, though, if you look at PostgreSQL adoption in my area (the San Francisco Bay Area and Silicon Valley), it's at least 80% Java and J2EE. In fact, of the 6 new clients I've signed in the last year, all of them were using Java as middleware and client. > The most successful (most quoted) advocacy articles I remember were the > once from OpenACS (Why not MySQL?) and sql-info.de (MySQL gotchas). To > make people look at PostgreSQL you should concentrate on why MySQL is > *bad*, to create a sense of insecurity in its users. That is the > propaganda that works. Unfortunately, this sort of propaganda can also backfire dramatically; the danger of mud-slinging is that you always seem to get some on yourself as well. Maybe it's different in Russia, but in the US I'd advocate pretty strongly against any really aggressive trashing of MySQL; the winner in that is liable to be the proprietary databases, not us. If you really want to reach the PHP coders where they live, though, just point out MySQL's licensing policy. If they want to use MySQL and *not* open-source their entire site, then they have to cough up $300 to $500US to MySQL AB as a commercial license, and pay for *each server* they use. That's a persuasive reason to switch to PostgreSQL. You can also point out that MySQL AB has changed the MySQL license 3 times since 2.0; what's to keep them from closing it entirely, and eliminating the Open Source version, if they feel it will be profitable? -- Josh Berkus Aglio Database Solutions San Francisco
Remember that MySQL for better or worse is tacking on features that Postgres was designed for 15 years ago. You could always do subqueries of a kind by using functions in the where clause. Surfacing the SQL only in 7.1 surprises me. elein On Mon, May 24, 2004 at 10:17:37AM -0400, Jan Wieck wrote: > Martin Marques wrote: > > > El Sáb 22 May 2004 20:00, Robert Bernier escribió: > >> http://det-dbalice.if.pw.edu.pl/det-dbalice/ttraczyk/db_compare/db_compare. > >>html > > > > I don't know when they wrote this but...: > > > > > > Subqueries in FROM clause > > > > Possibility of using subquery (nested query) in FROM clause of SQL query. > > > > MySQL: > > No. Will be added in next versions. > > > > Oracle8: > > Yes. > > > > Postgres: > > No. The feature will be supported from version 7.1. > > > > > > When was 7.1 released? 2001? > > Yeah, and funny enough, it's still "to be" included in the next version > of MySQL ... and what they have so far for 4.1 (in the 4.1.1 Alpha) is > one implementation of subselects for the FROM clause and apparently > another one for the WHERE clase (this is an assumption based on the fact > that subselects support different language features if they are in the > FROM clause or the WHERE clause). Fortunately I don't have to maintain > any of that code. > > > Jan > > -- > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #================================================== JanWieck@Yahoo.com # > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
Hi! Josh Berkus wrote: > First off, I'm glad you posted this. Our advocacy thinking tends to be > heavily US-dominated and I've wondered for a while how things are in your > part of the world. Well, they are somewhat different. For example, Russian version of MySQL's manual still sports the famous comparison with PostgreSQL: http://dev.mysql.com/doc/mysql/ru/Compare_PostgreSQL.html >>As the PostgreSQL advocacy group thinks that PHP programmers are among >>their *main* target audience, may I humbly suggest answering the >>questions that are asked instead of the ones that are not? > > Well, the first question I would ask *us* is whether or not PHP programmers > *are* among our main targets for advocacy. Based on my experience at > PHPCon, I would say that 80% of PHP coders would be well served by SQLite -- > MySQL is more powerful than they need or want, let alone us. That 80% of PHP coders do *not* go to conferences and are indeed best served by SQLite. But I am speaking about the other 20%, and if some of them switch that'll be extremely good: * advocacy within the community * quality web apllications that support PostgreSQL > Not that I'm writing off the PHP community. Given PostgreSQL's powerful > functions, views, and other in-database code, it makes a really dynamic > pairing with a lightweight scripting language like PHP -- one which I've used > to great effect. But I think that the target audience for this message is > not necessarily existing PHP jockeys, but rather coders in client-side > languages, and database designers used to Oracle and MSSQL, looking to move > to the web. OK, let's replace "PHP developers" by "current MySQL users". My point being, that most of them already know about features, and some of them even *want* these features. While there are some real problems preventing them from switching (lack of Win32 port, for instance), there also are some imagined ones and the natural aversion to change. >>The most successful (most quoted) advocacy articles I remember were the >>once from OpenACS (Why not MySQL?) and sql-info.de (MySQL gotchas). To >>make people look at PostgreSQL you should concentrate on why MySQL is >>*bad*, to create a sense of insecurity in its users. That is the >>propaganda that works. > > If you really want to reach the PHP coders where they live, though, just point > out MySQL's licensing policy. If they want to use MySQL and *not* > open-source their entire site, then they have to cough up $300 to $500US to > MySQL AB as a commercial license, and pay for *each server* they use. > That's a persuasive reason to switch to PostgreSQL. You can also point out > that MySQL AB has changed the MySQL license 3 times since 2.0; what's to keep > them from closing it entirely, and eliminating the Open Source version, if > they feel it will be profitable? Yes, and that is precisely the approach I called "creating a sense of insecurity". "You can get fired for choosing MySQL", "what happens when MySQL AB goes bankrupt?", etc. :] The recent article on licensing problems was noticed *very* well. I'd like to suggest doing the same things in technical perspective: why implementing the functionality on client side is *bad*, length of MySQL's release cycles, creating some "switching" stories, this kind of stuff.
On May 27, 2004, at 3:57 PM, Alexey Borzov wrote: > >>> As the PostgreSQL advocacy group thinks that PHP programmers are >>> among >>> their *main* target audience, may I humbly suggest answering the >>> questions that are asked instead of the ones that are not? >> Well, the first question I would ask *us* is whether or not PHP >> programmers *are* among our main targets for advocacy. Based on my >> experience at PHPCon, I would say that 80% of PHP coders would be >> well served by SQLite -- MySQL is more powerful than they need or >> want, let alone us. > > That 80% of PHP coders do *not* go to conferences and are indeed best > served by SQLite. But I am speaking about the other 20%, and if some > of them switch that'll be extremely good: > * advocacy within the community > * quality web apllications that support PostgreSQL > From our experience (dotgeek.org around 1000 PHP Developers hosted, no MySQL but only PostgreSQL/SQLite) users are still hocked with MySQL for the ease of use and phpmyadmin. Many are moving with pleasure and found postgresql as a pleasant surprise. They however cry loud more for the interface problems then anything else. As SQLite doesn't have a lot of frontends which works as well as phpmyadmin isn't that popular at the moment. >> Not that I'm writing off the PHP community. Given PostgreSQL's >> powerful functions, views, and other in-database code, it makes a >> really dynamic pairing with a lightweight scripting language like PHP >> -- one which I've used to great effect. But I think that the target >> audience for this message is not necessarily existing PHP jockeys, >> but rather coders in client-side languages, and database designers >> used to Oracle and MSSQL, looking to move to the web. > > OK, let's replace "PHP developers" by "current MySQL users". My point > being, that most of them already know about features, and some of them > even *want* these features. While there are some real problems > preventing them from switching (lack of Win32 port, for instance), > there also are some imagined ones and the natural aversion to change. Right, the simply don't like to change, not even to SQLite. problem is, there are few applications working with postgresql and tons working with php/mysql. > >>> The most successful (most quoted) advocacy articles I remember were >>> the >>> once from OpenACS (Why not MySQL?) and sql-info.de (MySQL gotchas). >>> To >>> make people look at PostgreSQL you should concentrate on why MySQL is >>> *bad*, to create a sense of insecurity in its users. That is the >>> propaganda that works. >> If you really want to reach the PHP coders where they live, though, >> just point out MySQL's licensing policy. If they want to use MySQL >> and *not* open-source their entire site, then they have to cough up >> $300 to $500US to MySQL AB as a commercial license, and pay for *each >> server* they use. That's a persuasive reason to switch to >> PostgreSQL. You can also point out that MySQL AB has changed the >> MySQL license 3 times since 2.0; what's to keep them from closing it >> entirely, and eliminating the Open Source version, if they feel it >> will be profitable? > > Yes, and that is precisely the approach I called "creating a sense of > insecurity". "You can get fired for choosing MySQL", "what happens > when MySQL AB goes bankrupt?", etc. :] I don't think that the majority of developers are concerned about that. The licensing leaves many developers untouched as long as they don't mess with MySQL Libs. MySQL advocacy is also very strong in reassuring the users. > > The recent article on licensing problems was noticed *very* well. > > I'd like to suggest doing the same things in technical perspective: > why implementing the functionality on client side is *bad*, length of > MySQL's release cycles, creating some "switching" stories, this kind > of stuff. > I think that devoting some resources (e.g. inviting more people to help) with the phppgadmin tool would be a great start. Cheers David Costa
On Tue, 2004-05-25 at 12:27, Josh Berkus wrote: > Well, the first question I would ask *us* is whether or not PHP programmers > *are* among our main targets for advocacy. Based on my experience at > PHPCon, I would say that 80% of PHP coders would be well served by SQLite -- > MySQL is more powerful than they need or want, let alone us. > > Not that I'm writing off the PHP community. Given PostgreSQL's powerful > functions, views, and other in-database code, it makes a really dynamic > pairing with a lightweight scripting language like PHP -- one which I've used > to great effect. But I think that the target audience for this message is > not necessarily existing PHP jockeys, but rather coders in client-side > languages, and database designers used to Oracle and MSSQL, looking to move > to the web. IMO, that's a great point. PostgreSQL seems like it's a good DBA's database and bluntly, MySQL is not. The inverse, I believe, can also be said. Which is, PostgreSQL is currently not a non-DBA's database. MySQL, on the other hand, gets lots of exposure to non-DBA's and does quite well. We really need some advocacy that talks to non-DBA users rather than the more technical crowd where PostgreSQL has long been well received. I would think the PHP crowd would fall more toward the non-DBA direction. -- Greg Copeland, Owner greg@copelandconsulting.net Copeland Computer Consulting 940.206.8004
Alexey Borzov wrote: > I'd like to suggest doing the same things in technical perspective: why > implementing the functionality on client side is *bad*, length of > MySQL's release cycles, creating some "switching" stories, this kind of > stuff. I am opposed to "advocating PostgreSQL" in this manner (regardless of how effective it may or may not be). Promoting PostgreSQL ought to be centered on explaining why PostgreSQL is a good DBMS, not trash-talking the competition. We should have faith that our users are capable of evaluating their database options and choosing the one that suites their needs best (which may or may not be PostgreSQL; I think Josh's point that SQLLite / MySQL are adequate for many people is a good one). -Neil
On 27 May 2004 at 15:28, Neil Conway wrote: > Alexey Borzov wrote: > > I'd like to suggest doing the same things in technical perspective: why > > implementing the functionality on client side is *bad*, length of > > MySQL's release cycles, creating some "switching" stories, this kind of > > stuff. > > I am opposed to "advocating PostgreSQL" in this manner (regardless > of how effective it may or may not be). Promoting PostgreSQL ought > to be centered on explaining why PostgreSQL is a good DBMS, not > trash-talking the competition. Neil is not alone in this position. If we can't stand on our merits, we should pack up and go home. > We should have faith that our users > are capable of evaluating their database options and choosing the > one that suites their needs best (which may or may not be > PostgreSQL; I think Josh's point that SQLLite / MySQL are adequate > for many people is a good one). I have no problem directing people to the right tool for the job. Sometimes that tool is PostgreSQL. Sometimes it is not. PostgreSQL cannot please everyone all the time. -- Dan Langille : http://www.langille.org/ BSDCan - http://www.bsdcan.org/
After a long battle with technology, dan@langille.org ("Dan Langille"), an earthling, wrote:
> I have no problem directing people to the right tool for the job.
> Sometimes that tool is PostgreSQL. Sometimes it is not. PostgreSQL
> cannot please everyone all the time.
It may well be a mistake to try to please all the people all the
time. I think that was exactly what Tom Christiansen had in mind when
he wrote:
"Huh? Windows was designed to keep the idiots away from Unix so we
could hack in peace. Let's not break that." -- Tom Christiansen
Microsoft tries to market Windows as being "all things for all
people;" much of its badness comes from that.
"If Ada became the hot, in-language you would see a lot more bad
code in Ada." -- Thaddeus L. Olczyk <olczyk@interaccess.com>,
comp.lang.C++
If PostgreSQL became as popular as MS-Access, we'd find people doing
hideous things with it. (Or, to be more precise, doing _even more
hideous_ things ;-).)
--
output = ("cbbrowne" "@" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/emacs.html "Is your pencil Y2K
certified? Do you know the possible effects if it isn't?"
> From our experience (dotgeek.org around 1000 PHP Developers hosted, no > MySQL but only PostgreSQL/SQLite) users are still hocked with MySQL for > the ease of use > and phpmyadmin. Many are moving with pleasure and found postgresql as a > pleasant surprise. They however cry loud more for the interface problems > then anything else. > > As SQLite doesn't have a lot of frontends which works as well as > phpmyadmin isn't that popular at the moment. I get a lot of people who are amazed at how good phpPgAdmin is. > I think that devoting some resources (e.g. inviting more people to help) > with the phppgadmin tool would be a great start. Have you actually used it recently? We kick phpMyAdmin's butt :) Chris
Hi! Neil Conway wrote: >> I'd like to suggest doing the same things in technical perspective: >> why implementing the functionality on client side is *bad*, length of >> MySQL's release cycles, creating some "switching" stories, this kind >> of stuff. > > > I am opposed to "advocating PostgreSQL" in this manner (regardless of > how effective it may or may not be). Promoting PostgreSQL ought to be > centered on explaining why PostgreSQL is a good DBMS, not trash-talking > the competition. And that is the problem with PostgreSQL advocacy effort: they explain why their product is *good*, while everyone else explains why their product is *better*. See my point? > We should have faith that our users are capable of > evaluating their database options and choosing the one that suites their > needs best (which may or may not be PostgreSQL; I think Josh's point > that SQLLite / MySQL are adequate for many people is a good one). I am not suggesting forcing PostgreSQL down the throats, either. I am speaking of people who may benefit from the switch (e.g. people who right *now* are considering switch to MySQL 4.1 or even 5.0), but need some *additional* push in the right direction.
On 5/27/2004 9:20 PM, Christopher Browne wrote: > If PostgreSQL became as popular as MS-Access, we'd find people doing > hideous things with it. (Or, to be more precise, doing _even more > hideous_ things ;-).) Exactly! The more "idiots" we make believe that we think PostgreSQL is the tool for them, the more "idiots" will run this sophisticated crashme (doing 10,000 CREATE TABLE, DROP TABLE), or they run the 571st variation of 10,000 INSERT, 10,000 single SELECT over one connection "benchmark". And this is not because they are biased, it is because that is the level of complexity they are capable of. They don't even think there could be something wrong with it, they are that simple. They do not need stored procedures because what they do can be done in 5 lines of PHP code. They do not need a view because there are only 3 tables in their schema. And they do not need MVCC because the 24 site hits per day querying 8 rows in their database wouldn't really benefit from it anyway. However, when they "port" their "applications" to PostgreSQL, it'll produce a lot of stupid noise based on ignorance and incompetence, with the net result that they "stick to MySQL" anyway. Nobody please get this wrong, there are a lot of serious people using MySQL today who are in need of a strong and powerfull database system. That is the reason why MySQL is tacking on features like crazy, features they have ignored for way too long. But those people do understand what we're talking about when we're doing it on the DBA level. We don't have to get down to the database-baby-talk. In fact, I think MySQL AB is currently talking exactly in that way, about 5 9's, NDB HA-clustering "integrated" into the "MySQL database engine". This is marketing babble directed at PHB's, bacause what they really "have" is yet another loosely tacked on table handler. Sure, it's linked into the same executable, but my understanding of "integration" goes a little further. Anyhow, what they do is they talk to "our" customers, the PostgreSQL users. They tell those who are waiting for replication and PITR that MySQL now has referential integrity, and that the next version will have multimaster replication while we are trying to educate dumbass PHP coders that transactions are a good thing (tm). That their multimaster NDB "sticker" is not integrated with the rest of the nice features like foreign keys doesn't matter. They get the foot into the door that way. And we all know that PHB's rather ruin a company than admitting to have been pulled over the table by a sales guy. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On 28 May 2004 at 10:36, Alexey Borzov wrote: > Hi! > > Neil Conway wrote: > >> I'd like to suggest doing the same things in technical perspective: > >> why implementing the functionality on client side is *bad*, length of > >> MySQL's release cycles, creating some "switching" stories, this kind > >> of stuff. > > > > > > I am opposed to "advocating PostgreSQL" in this manner (regardless of > > how effective it may or may not be). Promoting PostgreSQL ought to be > > centered on explaining why PostgreSQL is a good DBMS, not trash-talking > > the competition. > > And that is the problem with PostgreSQL advocacy effort: they explain why their > product is *good*, while everyone else explains why their product is *better*. > > See my point? One can explain why your product is better without trashing the competition. See our point? -- Dan Langille : http://www.langille.org/ BSDCan - http://www.bsdcan.org/
On Thursday 27 May 2004 11:36 pm, Alexey Borzov wrote:
>
> And that is the problem with PostgreSQL advocacy effort: they explain why
> their product is *good*, while everyone else explains why their product
> is *better*.
>
> See my point?
>
Compare the following two messages:
"MySQL is horrible. Use PostgreSQL."
versus:
"PostgreSQL is excellent. Use PostgreSQL."
In the end, that is what the PHBs (and PHP users and everyone else...) will
read and remember. Let's choose our message wisely.
I enjoy PostgreSQL half because it is superior and half because Tom Lane and
Josh Berkus and everyone else who is a contributor are just plain old nice
guys. Our community is built on friendly relationships within and without -
including the MySQL, Microsoft, and Oracle communities. Our community
includes rather than excludes. Our community encourages rather than
discourages. Our community compliments rather than criticizes. Let's keep
it that way.
--
Jonathan Gardner
jgardner@jonathangardner.net