That argument had as much merit the last time I heard it, when someone recommended PHP 4 over Perl.

If you'd spent all of the time you've spent making snide remarks about MySQL giving the actual factual technical reasons why PostgreSQL is better than MySQL in those cases where it is, you'd have done a lot more to convince people.

(Note to anyone else who wants to argue this: linking to MySQL Gotchas doesn't count for much in my book. Also be aware that I have used and still use MySQL, PostgreSQL, and SQLite.)

Indeed: why any particular database product? or server?

The answer is probably somewhere around "that's what hosting companies still offer", which is what a lot of people tell me when this topic comes up, but then they use all sorts of other advanced features that hosting companies usually don't support.

Because cross-database portability of SQL is still a myth. There are a lot of very, very similar flavours, and indeed the most basic of functionality is portable across dialects, however if you restrict yourself to factually portable SQL you'll very soon hit on limitations.

OTOH, a lot of the differences in the DQL and DML areas which concern the set of features common to all database engines are only superficial, ie syntactical. So assuming the database queries are properly encapsulated away from the application in a module as they should be, it wouldn't be hard to abstract away the differences between databases into several flavours of this module, of which one can then be selected by a configuration parameter.

What all that means is that it's preferrable to target a particular database at first and only refactor the business logic module that encapsulates the queries when time comes for that.

Makeshifts last the longest.

PostgreSQL? Why not?.. Everything is open for discussion! The plan is to build the best shopping cart. If PostgreSQL fits into that criteria, then I am all over it :)