It's easier to find work-arounds and translations from standard SQL to MySQL syntax, and do the same thing to translate to another reasonable database (Posgres, Oracle, MSSQL), than it is to reverse translate MySQL (or other database) specific features to other databases. Standard SQL is the sort of the greatest common factor (in the mathematical sense). Even more significantly, hundreds of MySQL people have spent significant effort in coming up with standard SQL equivalents in MySQL, so most of that work is already done for us. Maybe there is an open-source tool which can validate standard SQL which could be used. Then our DB abstraction could require a verifiable standard SQL syntax which would then be translated (where necessary) into the MySQL, Oracle, Postgres, etc. equivalents. This might only be for CRUD operations (data manipulation statements) and not for DDL, for which we already have a reasonable API and which are much less standardized. I myself always use MySQL for my Drupal installs -- because it will work. Thus, I never test them with Postgres, even though I run Postgres on several systems, am very comfortable with using it, etc. I just don't have the time to hassle with discovering some obscure SQL bug resulting from database incompatabilitilies when I'm just trying to make a site work. If I were able to devote more time to just testing Drupal for the sake of testing it and with no further purpose, I could and would use Postgres more of the time. But even then -- if my goal were to test the new menu code, I'd want to eliminate any other possible error causing sources, such as using Postgres. So unless we actually push the issue of supporting multiple databases as a community, the vast majority of developers will never make the effort. And with each passing release spent in that mode, the harder it will become to reverse it. We will end up supporting only one database, MySQL, de facto.