As long as a database engine has stored procedures and a decent client binding library, I can make it go. I've worked with MySQL, SAP/Sybase ASE, DB/2 LUW, PostgreSQL, Oracle, and SQL Server extensively over the years. There comes a point where you just know enough about the quircks and foibles of each of the databases to get around their particular issues and "just make it go."
People who bitch about the minor syntactic differences between the vendors clearly haven't really ported an application, because the differences in behaviour go far beyond syntactic sugar. Despite the ANSI standards, you can't just install the schema on a competitor's database and expect it to run an application properly without a lot of rework and restructuring.
Sure your basic table structures may remain compatible, but that's about it.
Every vendor has at least a few features that encourage "lock-in" by being incompatible with all their competitor's products.
I do have a rule about which databases I work with, though: if it doesn't have stored procedures, I won't use it. The performance benefits of complex stored procedures vs. logic in the client is just too dramatic to ignore and gloss over. Not to mention the fact that coding the logic in the client application is extremely verbose compared to any stored procedure syntax I've ever encountered.