I propose something much simpler: a procedure that takes an S-expression (perhaps generated by quasiquotation) and transforms it recursively based on little procedures for formatting individual clauses, a sort of run-time macroexpansion but producing a string (via a string port) rather than another S-expression.  For example:

    Strings would be properly quoted with apostrophes and escaped with double apostrophes; death to Little Bobby Tables!

    Numbers would be output as integral or decimal fractions (and throw an exception if they are complex)

    Arithmetic ops would recursively invoke their arguments and assemble them using infix ops in parentheses

    The "from" procedure would know to insert commas between the representations of its arguments, as would the "select" procedure up to the first appearance of a from-clause or the end of arguments.

    A symbol just turns into its name, quoting with double quotes if necessary.

These behaviors would be built-in, but could be overridden or supplemented by a mapping from symbols to procs provided in a parameter.  When finding a list whose car is an unknown symbol, we assume that it's a call on a SQL function, and generate it in proper SQL syntax "f(a, b, c)".

Advantages: no need for SQL parameters because string escaping is built in and substitution is done in a way that's familiar to Schemers; if you want to break the rules you just don't use this procedure and pass a plain string; it can be developed separately from the main SQL SRFI.

Disadvantages: doesn't prevent gibberish from being written that will cause SQL syntax errors, like (select (order-by g) (+ 2 3)) => "SELECT ORDER BY g (2 + 3)".

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Humpty Dump Dublin squeaks through his norse
                Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
                Humpty Dump Dublin's grandada of all rogues.  --Cousin James