I think it does an ok job, but that's not really it's goal.
True enough.
I also don't think this is super important.
Agreed.
You pick a particular DBMS because you think it's the right tool for the job.
Or you've got one database you use for everything regardless of whether its the right one or not.
Only in a few rare cases (apps written for wide distribution) is there any reason to consider portability across DBMS backends.
Given that I'd like to see Perl extend its lead in terms of awesomeness in all things the rare case fo wide distribution is important to me. I'm a bugzilla helper/hanger-on and folks ask about PostgreSQL and Sybase ports all the time. It'd be nice if it "just worked".
I've never written an app for a client that started on one backend and moved to another.
Less than 10% of my clients have ever specified what the database backend need to be, but we've recently had a client that has decided to move from MySQL to PostgreSQL so we've been having to port SQL for the first time in ages. People whine about MySQL's lack of features, but in terms of available SQL syntax its a lot easier-going and handier than PostgreSQL.
I imagine that if this were to happen, it'd be because the new backend provided some set of features that were now important to the app, and some code changes would be necessary to take advantage of this.
Or the priests of IT get bored and decide to change directions. In this case its a large government agency creating useless policy where the defacto was perfectly fine. Beaurocrats can s~&k my left n*t. :) The same folks want to rewrite all the Perl in the whole org into PHP. It doesn't seem to have dawned on them that this is physically impossible considering some of the things Perl is doing, but I'm sure they'll unleash a large enough horde to overcome it. Sadly.
-- </chris>
"Fans of Mozilla's free, open-source Firefox browser make the ardent Apple faithful look like a bunch of slackers." - Rebecca Lieb at clickz.com
