If you are going to do that, why not just skip SQL, take what is good from SQL, and apply Perlisms to it?

I.e. instead of SELECT foo FROM bar WHERE baz is not true; why not come up with an SQL-inspired interface that avoids the parsing issues, something like:

    select(    columns => ['foo'], 
           start_table => 'bar',
             condition => '? or !defined ?',
                  bind => ['baz', 'baz']
    );
[download]

This would avoid the parsing problems, allow you to add joins, cte's, inline views, and more if you ever need it. It would avoid the hard problems while giving you something where you and your successor could leverage sql knowledge. That means essentially passing in the parse tree rather than the declarative statement to the function, and as such it also avoids the possibility of sql injection.

Good point; but it's not the interface I care about. I'm not insisting that it be SQL. What I'm looking for is a replacement for the bletcherous blob of an engine I wrote. I assume (yeah, I know) that an engine that implements an SQL interface will be able to do what I want. If I can get the engine without the SQL, that's fine too.