UncommonSQL is an implementation of CommonSQL by some other people (Pierre R. Mai et. al.) I'm in the process of making an adjustment to that makes using parametrized sql strings in the database backends possible. This is made necessary and desireable by the fact that the PostgreSQL backend does not handle strings with embedded null characters, it simply barfs on them. It is likely there is some other database system that would have the same problem.
Update: PostgreSQL does not in fact have parametrized sql strings at all. This work is important for the Interbase backend I'm working on, however.
The deal is to do magic in the generic function
database-output-sql which normally transforms the
%sql-expressions into strings. Where previously
values where transformed into literals, they are now transformed
into question marks, the position of the question mark is guessed
and the value corresponding to this question mark is stored into a
list in the database object. When the string is actually sent in
database-query, database-execute-command
or database-query-result-set, the values are then
found via the database object and sent to the database engine by
the appropriate method for parametric sql for the database in
question. The value list is then set to null, and then
accumulation of the next list of parametric values can begin.
I furthermore conjecture that using parametrized sql is faster for operations where the values are of any significant length. With small operations the setup time dominates anyway.