If you want to be really database-independent, then think about this:

First:

• SQL is currently not database independent
• parsing SQL is too hard
• means you have to build on top of that

Second:

• it is very easy to solve your problem for each specific database engine
• it is very hard to solve it in general

Therefore:

• design an API (a bunch of functions) that does the tasks you need
• build a simple interpreter function that calls these functions (an "apply()" for your API)
• then you can simply re-implement these functions for each new database engine (which is trivial for a single engine)
• and add a handler for the engine to a table of database engine handlers
• make the interpreter take a reference to the appropriate engine

I used this approach for a lot of database-handling tasks from CGI scripts to online-database-coupling-interfaces, and it scales very well.

Specifically, I believe that anything relying on somehow working with "standardized" SQL is doomed from the beginning. The different SQL dialects are simply to different to achieve this.

If you want to be database independent, you will need an abstraction layer above the database level - and this means no particular database engine features may surface at this layer of abstraction.

Just my 2 cent ...

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com