Re: Technical refresh->Why MySQL?

At 01:04 12-08-01, Ron Chmara wrote: A few things stand out as possible differences:

1. The default install comes with MySQL support already built in, by default. Microsoft is undergoing several anti-trust lawsuits for a similar reason, because I think it's been been demonstrated that the default install is what folks will tend to use. Why not PostgreSQL support as well? (Of course, if every extension with active proponents had working libraries available in the default PHP install... Wow, that _would_ be pretty cool. A much bigger download, but a massive leap forward in terms of resolving basic installation and configuration issues. I'd rather spend 20 more minutes on ftp than spend 2 hours building other libraries....Of course, it requires much tighter communication to handle licensing issues, and prior problems with this may have lead to some "burn out" on this idea.).

Simple reason - MySQL is a hell of a lot more popular than PostgreSQL, at least in conjunction with PHP usage. As a matter of fact, one of the main reasons we did that was to avoid the daily routine of a couple of "Why do I get mysql_connect(): Call to undefined function???!!!" messages on php-general. Perhaps it's because PostgreSQL users are always smarter :), perhaps it's because it's not as popular, but the bottom line is that we never had a similar problem with PostgreSQL. Nonetheless, I can't wait till the DOJ presses antitrust charges against php-dev ;)

2. Bug fixes for basic things such as connection handling have "seemed" to take much longer, perhaps that's merely perceptual on my part, or a lack of contributors, or the maintainers are swamped. (There was actually a big bug with *_pconnects, because PostgreSQL runs into a shared memory wall, and stops accepting connections.... but it looks like it was possibly fixed in CVS, even though there's still bug listings for it). OTOH, there's a lot _less_ outstanding bugs, so like I said, it may be perceptual, or related to bugs that are more important in the code I maintain, but less important to others.

I don't think there were any serious bugs in the MySQL module for quite a while. There was some obscure pconnect() problem a while ago, but the main reason it wasn't fixed right away was that I wasn't aware of its existence. Yes, I don't actively maintain the MySQL module, anymore than I continue to maintain my old PostgreSQL module. The main reason is that it's been rock solid for years (except for this pconnect issue about a year ago).

3. It wasn't until June 19th, (thanks again, Georg von Zezschwitz! You rock!) that much of the pgsql extension had the same ease of use as the MySQL extensions. PostgreSQL required additional coding for, well, almost everything involving a row. This had been in place as long as I've used PostgreSQL+PHP, and it probably just an artifact of different coding styles. This had an effect where even basic PHP+PostgreSQL examples looked "harder", and took longer to write (additional loop calls, counters, etc.). (Oops.. this still isn't documented, either...). Since it takes a bit for such things to trickle down through publications, examples, docs, and tutorials, PHP+PostgreSQL will look like it's "harder" to use than PHP+MySQL for quite a while. I guess this is sort of fixed now, and will get better as time goes by, and documentation gets changed or cleaned up.

Well, not exactly different coding styles :) Unfortunately, I made a wrong decision when I was writing the PostgreSQL module, to try and copy the PHP/FI 2 API, instead of unifying it to be like the MySQL module. I made several of those mistakes at the time (e.g. parentheses-free echo), as it did seem important at the time. It's always easier to be smart in retrospect... Zeev