Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

On 28/11/2003 17:10 Jason Tesser wrote:
> [snip]
>
> I completely disagree. I do a lot of programming with PHP and the
> features
> of Postgres come in handy. Let me give you an example of just some
> basic things. Triggers! Why should I have to write insert and update
> triggers in the logic (PHP) if I can handle it at the database level.
> Sql
> is 10x as fast as the language. Better to handle what you can at the
> database
> level. Same with views and stored procedures.

Stored procedures can be a 2-edged sword. They can lead to business logic
being scattered between the persistence layer and the business layer.
Thats not good for maintaining the application 3 years down the line.
Triggers can also cause maintenance problems. Its so easy to forget/fail
to document that inserting a record into table x causes column y of table
z to be updated. Be careful how and where you use these features as they
can come back to bite you!

> MySQL cannot even handle
> sub-queries yet. I also use Python for standalone interfaces to the data.
>
> Why should I not be able to use the same views and triggers etc in there
> that I use for my web apps. PHP is quite powerful if used correctly.

You are, of course, free to do whatever want. But if you have to use
features of the database to compensate for inadequacies in your
programming language maybe you should be using another language?

> Java has its own issues and I am not sure it is as far supiour as you
> are claming it is. But that is not for this dscussion.

I'm not aware of any "issues" with Java (unless you mean Swing ;)).
> MySQL may be more
> popular with (cheap) web hosting places but that doesn't mean it is the
> best
> or that Postgres wouldn't serve better even in this area. I am glad
> to see the article written for PHP mag as Postgres would help alot of PHP
> guys that are using MySQL.

Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
support for it. With the MySQL client library license change, this
situation will probably change. There was a long thread about this earlier
this year. Check the archives.

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+

> > Java has its own issues and I am not sure it is as far supiour as you
> > are claming it is. But that is not for this dscussion.
>
> I'm not aware of any "issues" with Java (unless you mean Swing ;)).

I know for one thing - Java's lack of support for returning tuples is
hugely annoying.

Jon

Paul Thomas wrote:
>
>
>
> On 28/11/2003 17:10 Jason Tesser wrote:
> > [snip]
> >
> > MySQL cannot even handle
> > sub-queries yet. I also use Python for standalone interfaces to
> the data.
> >
> > Why should I not be able to use the same views and triggers etc
> in there
> > that I use for my web apps. PHP is quite powerful if used correctly.
>
> You are, of course, free to do whatever want. But if you have to use
> features of the database to compensate for inadequacies in your
> programming language maybe you should be using another language?

This doesn't even make sense in the context of Jasons remark.

>
> > Java has its own issues and I am not sure it is as far supiour as you
> > are claming it is. But that is not for this dscussion.
>
> I'm not aware of any "issues" with Java (unless you mean Swing ;)).
> > MySQL may be more
> > popular with (cheap) web hosting places but that doesn't mean it is the
> > best
> > or that Postgres wouldn't serve better even in this area. I am glad
> > to see the article written for PHP mag as Postgres would help
> alot of PHP
> > guys that are using MySQL.
>
> Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> support for it. With the MySQL client library license change, this
> situation will probably change. There was a long thread about
> this earlier
> this year. Check the archives.
>
>
This is incorrect. The embedded mysql client library was not added until
PHP4.0 RC1. PHP's popularity existed long before this. The real culprit
causing the popularity of MySQL was it's ubiquity among hosting providers
and the virtual non-existence of PG in that arena. If PG had been more
friendly to shared hosting environments, perhaps this situation wouldn't
have arisen. Blaming PHP for this situation (and your other comments) show
extreme prejudice.

From: "Paul Thomas" <paul(at)tmsl(dot)demon(dot)co(dot)uk>:
> Stored procedures can be a 2-edged sword. They can lead to business logic
> being scattered between the persistence layer and the business layer.
> Thats not good for maintaining the application 3 years down the line.
> Triggers can also cause maintenance problems. Its so easy to forget/fail
> to document that inserting a record into table x causes column y of table
> z to be updated. Be careful how and where you use these features as they
> can come back to bite you!

It is all how you organize your app. Stored proceedures are extremely
useful when they represent a unified API for accessing parts of the
database. Word of advice: Keep the database self-contained. If all you
want is object persistance, then why non use Berkeley Database? It is even
transactional. The point of having an RDBMS is to provide more flexibility
than a simple persistance store. When used sensibly, stored proceedures are
extremely simplifying, not the other way arround.

> >
> > Why should I not be able to use the same views and triggers etc in
there
> > that I use for my web apps. PHP is quite powerful if used correctly.
>
> You are, of course, free to do whatever want. But if you have to use
> features of the database to compensate for inadequacies in your
> programming language maybe you should be using another language?

I don't think Jason was compensating for weaknesses in the language-- I
think that he was asking why he woudln't want to build into the database the
universal functions accessed by multiple applications. And he would be
right in trying to do so.

Let me give you an example: One of the large projects I maintain is HERMES
(http://hermes.sourceforge.net). Hermes relies on its own user and
permissions catalogs in order to provide a consistant administrative
interface across database managers and simplify the task of assigning
permissions to users and groups. The differences in syntax can them be
handled in wrapper layers, etc.

However, it makes sense to try to wrap these catalogs using stored
proceedures so that third-party apps don't necessarily need to be aware of
the structure of the catalogs when assigning permissions. This way, too,
the db users' catalog and the user catalog in the RDBMS can be guaranteed to
be in sync. It will also allow me eventually to directly enforce
permissions using triggers rather than rely on the RDBMS model (useful in
shared hosting environments).

>
> > Java has its own issues and I am not sure it is as far supiour as you
> > are claming it is. But that is not for this dscussion.
>
> I'm not aware of any "issues" with Java (unless you mean Swing ;)).

Every language has "issues." This is not the time or place for a
development environemnt holy war ;-) But--- PHP and Python all the way ;-)

>
> Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> support for it. With the MySQL client library license change, this
> situation will probably change. There was a long thread about this earlier
> this year. Check the archives.
>
Putting the cart before the horse. MySQL is far easier to administer in a
shared hosting environment. Maybe one of these days, I will put together a
package for managing PostgreSQL accounts in this way. If there is interest,
please email me off-list and we can get started. I don't expect MySQL's
dominance to change until we can offer an easy-to-administer alternative for
these environments.

Best Wishes,
Chris Travers

El Sáb 29 Nov 2003 08:45, Paul Thomas escribió:
> On 28/11/2003 17:10 Jason Tesser wrote:
> > [snip]
> >
> > I completely disagree. I do a lot of programming with PHP and the
> > features
> > of Postgres come in handy. Let me give you an example of just some
> > basic things. Triggers! Why should I have to write insert and update
> > triggers in the logic (PHP) if I can handle it at the database level.
> > Sql
> > is 10x as fast as the language. Better to handle what you can at the
> > database
> > level. Same with views and stored procedures.
>
> Stored procedures can be a 2-edged sword. They can lead to business logic
> being scattered between the persistence layer and the business layer.
> Thats not good for maintaining the application 3 years down the line.
> Triggers can also cause maintenance problems. Its so easy to forget/fail
> to document that inserting a record into table x causes column y of table
> z to be updated. Be careful how and where you use these features as they
> can come back to bite you!

Please, don't blame the feature. Blame the poor documentation that the
programmer did.

If you program the right way from the beginning, Stored Procedures, Views,
Triggers, etc. are great for getting good performace applications. And it is
the way DB Apps Designers should work, IMHO.

--
10:42:02 up 3 days, 17:06, 1 user, load average: 0.01, 0.02, 0.06
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------

On 29/11/2003 12:53 Rod K wrote:
> [snip]
> > You are, of course, free to do whatever want. But if you have to use
> > features of the database to compensate for inadequacies in your
> > programming language maybe you should be using another language?
>
> This doesn't even make sense in the context of Jasons remark.

It makes sense to me. Maybe English is a write-only language after-all ;-)

> [snip]
> > Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> > support for it. With the MySQL client library license change, this
> > situation will probably change. There was a long thread about
> > this earlier
> > this year. Check the archives.
> >
> >
> This is incorrect. The embedded mysql client library was not added until
> PHP4.0 RC1.

Thats not the impression I got from from reading the thread concening
MySQL/PHP et al earlier this year. But whatever the exact historical
details are, the current popularity of MySQL as the back-end for PHP apps
is well-documented.

> PHP's popularity existed long before this. The real culprit
> causing the popularity of MySQL was it's ubiquity among hosting providers
> and the virtual non-existence of PG in that arena. If PG had been more
> friendly to shared hosting environments, perhaps this situation wouldn't
> have arisen.

I think culprit is a bit strong. If I were in the hosting business a few
years ago I would probably have made the same decision on the belief that
most people would not need anything more than a few rudimentary database
features for which MySQL would suffice.
> Blaming PHP for this situation (and your other comments) show
> extreme prejudice.

Where have I blamed PHP for anything? Nowhere. As for extreme predudice,
if you wish to grosely mis-interpret my opinions of the limitations of cgi
scripts in that way, thats fine by me.

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+

Paul Thomas wrote:
>
>
> On 29/11/2003 12:53 Rod K wrote:
> > [snip]
> > > You are, of course, free to do whatever want. But if you have to use
> > > features of the database to compensate for inadequacies in your
> > > programming language maybe you should be using another language?
> >
> > This doesn't even make sense in the context of Jasons remark.
>
> It makes sense to me. Maybe English is a write-only language after-all ;-)
>

Jason wrote:
"I also use Python for standalone interfaces to the data. Why should I not
be able to use the same views and triggers etc in there
that I use for my web apps."

Now, how is your comment about "language inadequacies" relevent? Wanting to
use the RDBMS to handle business logic makes perfect sense, especially when
multiple front ends will be accessing. This has nothing to do with
perceived "inadequacies."

> > [snip]
> > > Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> > > support for it. With the MySQL client library license change, this
> > > situation will probably change. There was a long thread about
> > > this earlier
> > > this year. Check the archives.
> > >
> > >
> > This is incorrect. The embedded mysql client library was not
> added until
> > PHP4.0 RC1.
>
> Thats not the impression I got from from reading the thread concening
> MySQL/PHP et al earlier this year. But whatever the exact historical
> details are, the current popularity of MySQL as the back-end for PHP apps
> is well-documented.

It is your choice to believe your impressions of those posts or do the
research. The popularity of MySQL as a back-end for PHP has to do with the
popularity of MySQL. Not because of "PHPs out-of-the-box support for it."
In fact, the popularity of MySQL as a back-end LED TO the incorporation of
the MySQL client API in PHP. You've reversed cause and effect. The
popularity of MySQL stems from the popularity of MySQL among hosting
providers. The popularity of MySQL among hosting providers comes from the
ease of administration of MySQL vs Postgres in those environments.

>
> > PHP's popularity existed long before this. The real culprit
> > causing the popularity of MySQL was it's ubiquity among hosting
> providers
> > and the virtual non-existence of PG in that arena. If PG had been more
> > friendly to shared hosting environments, perhaps this situation wouldn't
> > have arisen.
>
> I think culprit is a bit strong. If I were in the hosting business a few
> years ago I would probably have made the same decision on the belief that
> most people would not need anything more than a few rudimentary database
> features for which MySQL would suffice.
> > Blaming PHP for this situation (and your other comments) show
> > extreme prejudice.
>
> Where have I blamed PHP for anything? Nowhere.

You quoted yourself and still missed it. Here it is again:

"Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
support for it."

As for extreme predudice,
> if you wish to grosely mis-interpret my opinions of the
> limitations of cgi
> scripts in that way, thats fine by me.
>

Coloring reality with your "opinions" is prejudicial, like it or not.

Quoted as gospel by various people:
>> MySQL cannot even handle sub-queries yet.

BTW, is that really still true? I thought they had at least some
support for subqueries by now.

regards, tom lane

They do in alpha quality 4.1.x series I believe.

http://www.mysql.com/doc/en/MySQL_4.1_Nutshell.html

Regards

T.

Tom Lane wrote:

>Quoted as gospel by various people:
>
>
>>>MySQL cannot even handle sub-queries yet.
>>>
>>>
>
>BTW, is that really still true? I thought they had at least some
>support for subqueries by now.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>

"Rod K" <rod(at)23net(dot)net> writes:
> Paul Thomas wrote:
>> Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
>> support for it.

> This is incorrect. The embedded mysql client library was not added until
> PHP4.0 RC1. PHP's popularity existed long before this. The real culprit
> causing the popularity of MySQL was it's ubiquity among hosting providers
> and the virtual non-existence of PG in that arena. If PG had been more
> friendly to shared hosting environments, perhaps this situation wouldn't
> have arisen.

You are both engaging in the most blatant form of historical
revisionism. Of course PHP's support for MySQL didn't drive MySQL
adoption --- it was the other way around, PHP adapted to MySQL because
that was what was out there. I think "friendly to shared hosting
environments" is a made-up reason as well. The real reason PG lost
mindshare to MySQL in the early web days is that at the time, PG was
hard to install, somewhat buggy, and poorly documented. (Which was not
surprising considering that none of these mattered much in its original
academic environment.) MySQL didn't do much, maybe, but what it could
do it did pretty well and without install/learning curve hassles. We
had mostly caught up on those criteria by perhaps 7.1 or 7.2, but the
mindshare gap remains.

regards, tom lane

Tom,
>
>
> "Rod K" <rod(at)23net(dot)net> writes:
> > Paul Thomas wrote:
> >> Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> >> support for it.
>
> > This is incorrect. The embedded mysql client library was not
> added until
> > PHP4.0 RC1. PHP's popularity existed long before this. The
> real culprit
> > causing the popularity of MySQL was it's ubiquity among hosting
> providers
> > and the virtual non-existence of PG in that arena. If PG had been more
> > friendly to shared hosting environments, perhaps this situation wouldn't
> > have arisen.
>
> You are both engaging in the most blatant form of historical
> revisionism.

I am? I mis-spoke (see below) but my point was clear and you stated the
same.

Of course PHP's support for MySQL didn't drive MySQL
> adoption --- it was the other way around, PHP adapted to MySQL because
> that was what was out there.

My point.

I think "friendly to shared hosting
> environments" is a made-up reason as well. The real reason PG lost
> mindshare to MySQL in the early web days is that at the time, PG was
> hard to install, somewhat buggy, and poorly documented.

"...friendly to shared hosting environments" was not exactly what I meant to
say. It WAS a PITA for HOSTING PROVIDERS for exactly the reasons you state,
which is why MySQL was usually chosen.

(Which was not
> surprising considering that none of these mattered much in its original
> academic environment.) MySQL didn't do much, maybe, but what it could
> do it did pretty well and without install/learning curve hassles. We
> had mostly caught up on those criteria by perhaps 7.1 or 7.2, but the
> mindshare gap remains.
>
Agreed

I agree... as a newcomer to PG from MySQL and a web hosting provider, PG
is no more difficult to admin than MySQL IMHO. Just requires a little
understanding. But with tools like PGAdmin, even the understanding
required is reduced.

I beleive that MySQL just achieved a snowball effect, and that's just
the way it happened. PG is easy to install. Although one hold-up has
to be the fact that I for instance can't run PG on my works laptop that
runs XP (without significant hassle). My laptop is where I prototype
all of my applications (if I am able) and my life would be sooo much
easier if I could run a PG server alongside my various other bits of
IDE. I tend to be a little more tenacious than most, I'm sure if I find
it hassle, then others do too. Many developers that I know of, use a
windows machine and dev tools, to develop what will eventually be a Unix
app. Just easier that way sometimes.

Credit cards are easy to use, in fact their darn difficult not to use.
MySQL is similar to this, when they announce a new release, the release
is available not only as source, but .exe and a dozen other platforms
all waiting to be used. So it's a really easy decsion to make if you
know that you can run your DB anywhere. Install it from RPM, or .exe.

Just my 2 cents again.

T.

Tom Lane wrote:

>"Rod K" <rod(at)23net(dot)net> writes:
>
>
>>Paul Thomas wrote:
>>
>>
>>>Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
>>>support for it.
>>>
>>>
>
>
>
>>This is incorrect. The embedded mysql client library was not added until
>>PHP4.0 RC1. PHP's popularity existed long before this. The real culprit
>>causing the popularity of MySQL was it's ubiquity among hosting providers
>>and the virtual non-existence of PG in that arena. If PG had been more
>>friendly to shared hosting environments, perhaps this situation wouldn't
>>have arisen.
>>
>>
>
>You are both engaging in the most blatant form of historical
>revisionism. Of course PHP's support for MySQL didn't drive MySQL
>adoption --- it was the other way around, PHP adapted to MySQL because
>that was what was out there. I think "friendly to shared hosting
>environments" is a made-up reason as well. The real reason PG lost
>mindshare to MySQL in the early web days is that at the time, PG was
>hard to install, somewhat buggy, and poorly documented. (Which was not
>surprising considering that none of these mattered much in its original
>academic environment.) MySQL didn't do much, maybe, but what it could
>do it did pretty well and without install/learning curve hassles. We
>had mostly caught up on those criteria by perhaps 7.1 or 7.2, but the
>mindshare gap remains.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
>

In article <7515(dot)1070124713(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Quoted as gospel by various people:
>>> MySQL cannot even handle sub-queries yet.

> BTW, is that really still true? I thought they had at least some
> support for subqueries by now.

Subqueries are supported in MySQL 4.1 which came out some months ago,
but this version is (rightfully) not yet declared stable.

On 29/11/2003 13:41 Chris Travers wrote:
> [snip]
> It is all how you organize your app. Stored proceedures are extremely
> useful when they represent a unified API for accessing parts of the
> database. Word of advice: Keep the database self-contained. If all you
> want is object persistance, then why non use Berkeley Database? It is
> even
> transactional. The point of having an RDBMS is to provide more
> flexibility
> than a simple persistance store. When used sensibly, stored proceedures
> are
> extremely simplifying, not the other way arround.

Actually I've worked on projects where views and stored procedures have
been used to present a logical view of the underlying data and help to
isolate the application from database changes. I think this is an entirely
reasonable thing to do. Berkely DB me? Never! PostgreSQL rules! :)

> [snip] I don't think Jason was compensating for weaknesses in the
> language-- I
> think that he was asking why he woudln't want to build into the database
> the
> universal functions accessed by multiple applications. And he would be
> right in trying to do so.
>
> Let me give you an example: One of the large projects I maintain is
> HERMES
> (http://hermes.sourceforge.net). Hermes relies on its own user and
> permissions catalogs in order to provide a consistant administrative
> interface across database managers and simplify the task of assigning
> permissions to users and groups. The differences in syntax can them be
> handled in wrapper layers, etc.
>
> However, it makes sense to try to wrap these catalogs using stored
> proceedures so that third-party apps don't necessarily need to be aware
> of
> the structure of the catalogs when assigning permissions. This way, too,
> the db users' catalog and the user catalog in the RDBMS can be guaranteed
> to
> be in sync. It will also allow me eventually to directly enforce
> permissions using triggers rather than rely on the RDBMS model (useful in
> shared hosting environments).
>
> >
> > > Java has its own issues and I am not sure it is as far supiour as you
> > > are claming it is. But that is not for this dscussion.
> >
> > I'm not aware of any "issues" with Java (unless you mean Swing ;)).
>
> Every language has "issues." This is not the time or place for a
> development environemnt holy war ;-) But--- PHP and Python all the way
> ;-)

Python? Hm. Is this the 5 minute argument or the full half hour? :-)

>
> >
> > Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> > support for it. With the MySQL client library license change, this
> > situation will probably change. There was a long thread about this
> earlier
> > this year. Check the archives.
> >
> Putting the cart before the horse. MySQL is far easier to administer in
> a
> shared hosting environment. Maybe one of these days, I will put together
> a
> package for managing PostgreSQL accounts in this way. If there is
> interest,
> please email me off-list and we can get started. I don't expect MySQL's
> dominance to change until we can offer an easy-to-administer alternative
> for
> these environments.

Why not contribute to one of the existing PG admin utilities such as
pgAdmin III or phpPgAdmin?

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+

El Sáb 29 Nov 2003 13:51, Tom Lane escribió:
> Quoted as gospel by various people:
> >> MySQL cannot even handle sub-queries yet.
>
> BTW, is that really still true? I thought they had at least some
> support for subqueries by now.

Sorry if it's a stupid question, but what's the difference between subqueries
and subselects?

--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
-----------------------------------------------------------------
Martín Marqués | mmarques(at)unl(dot)edu(dot)ar
Programador, Administrador, DBA | Centro de Telemática
Universidad Nacional
del Litoral
-----------------------------------------------------------------

Martin Marques writes:

> Sorry if it's a stupid question, but what's the difference between subqueries
> and subselects?

Nothing.

--
Peter Eisentraut peter_e(at)gmx(dot)net

El Dom 30 Nov 2003 10:21, Peter Eisentraut escribió:
> Martin Marques writes:
>
> > Sorry if it's a stupid question, but what's the difference between
subqueries
> > and subselects?
>
> Nothing.

Wow, I thought that they were different things.
I could swear that I say a press release saying they had it in 4.0. That's why
I thought that they were different things.

--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
-----------------------------------------------------------------
Martín Marqués | mmarques(at)unl(dot)edu(dot)ar
Programador, Administrador, DBA | Centro de Telemática
Universidad Nacional
del Litoral
-----------------------------------------------------------------

I used it first because

1) someone suggested it and I didn't know any better
2) install, setup, maintanance and using it is easier than breathing. You'd
be surprised how much of a difference it makes to a newbie to not have to do
things like vacuum regularly and the ability to change a column type (I'm
not saying this is a good idea, just that it seemed nice at the time), stuff
like that.
3) their online documentation was great, learning how to do new stuff was
fast and easy
4) It SEEMED to work fine (I say seemed because I never had anything happen
to me like an int overflow problem)
5) For the type of work I started off with I didn't badly need the features
that mysql lacks

I'm betting that this is the case with many mysql users.

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: <pgsql-general(at)postgreSQL(dot)org>
Sent: Saturday, November 29, 2003 10:01 AM
Subject: Re: Triggers, Stored Procedures, PHP. was: Re: [GENERAL] PostgreSQL
Advocacy, Thoughts and Comments

> "Rod K" <rod(at)23net(dot)net> writes:
> > Paul Thomas wrote:
> >> Much of the populatity of MySQL seems to stem from PHPs out-of-the-box
> >> support for it.
>
> > This is incorrect. The embedded mysql client library was not added
until
> > PHP4.0 RC1. PHP's popularity existed long before this. The real
culprit
> > causing the popularity of MySQL was it's ubiquity among hosting
providers
> > and the virtual non-existence of PG in that arena. If PG had been more
> > friendly to shared hosting environments, perhaps this situation wouldn't
> > have arisen.
>
> You are both engaging in the most blatant form of historical
> revisionism. Of course PHP's support for MySQL didn't drive MySQL
> adoption --- it was the other way around, PHP adapted to MySQL because
> that was what was out there. I think "friendly to shared hosting
> environments" is a made-up reason as well. The real reason PG lost
> mindshare to MySQL in the early web days is that at the time, PG was
> hard to install, somewhat buggy, and poorly documented. (Which was not
> surprising considering that none of these mattered much in its original
> academic environment.) MySQL didn't do much, maybe, but what it could
> do it did pretty well and without install/learning curve hassles. We
> had mostly caught up on those criteria by perhaps 7.1 or 7.2, but the
> mindshare gap remains.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>