"MySQL's paradigm is fatally app-centric, however and I have a hard time seeing that as a good thing. I'd be happier if the app-centric db chosen was SQLite or Firebird DB."
I googled app-centric after reading this and I've come up with comparisions made with mouse-centric, computer-centric, user-centric and I don't really understand it. Are you using it as a synonym for single-user?
Basically the issue has to do with how MySQL folks and PostgreSQL folks see the RDBMS.
MySQL users see the RDBMS as the bottom tier for the applications they are developing. Consequently the system's design is aimed at letting the application steer the interaction. If the application wants to treat 30 February as a valid date, that's the application's call and the app can set sql_mode appropriately and allow such values to be stored or not.
In other words, with MySQL, the db is there primarily to serve the application.
With PostgreSQL, it's very different. The database is there not to serve the application but to manage data. The applications are just users of that managed data. In this model the database has a very different responsibility. You might therefore call PostgreSQL data-centric. Applications cannot decide how strict data handling should be because that would defeat the whole purpose of the RDBMS in the PostgreSQL worldview, which is the system which manages and ensures meaningfulness of data.
So MySQL sees the RDBMS as ultimately serving (and being accountable to) the applications and app developers. PostgreSQL sees it as ultimately being accountable to the data and DBA's. The problem is that this makes MySQL have trouble when multiple codebases are used to access the same data since each application could conceivably be operating on different sql_mode settings. Each application can therefore be seen to be interfering with the other apps' state rather than all consuming shared managed data.
ok. There are some braindead things that Firebird does too particularly regarding Null handling. However they are consistent and predictable. You don't have the variability in rules and corner cases that you do in MySQL.
One of the things I really liked about Firebird the last time I played with it is that it could be run over a socket or embedded as a library. The PostgreSQL community will not provide a library engine because of the fear that application bugs may cause corrupted data structures in the library. Again this is wholely consistent with PostgreSQL not really caring about the single app space that much.
What this means is that if you want to distribute an application, you can actually directly link your application to the database management component directly and this simplifies the management of your app. If you need to later move the app up to a dedicated server you can do that. Firebird makes this really easy and it does so without creating the flexibility on input (and hence the fact that so many variations must be handled on output) that MySQL does.