Looking a bit deeper into the issue of passing values directly to prepared statements -- one thing we'd have to do first is define some kind of consistent interface. Right now the rules for what you may pass in there and how they get treated are completely inconsistent. I'm not sure how to clean this up without adding overhead or cruft, though.
the following is my mental model about the issue (which is obviously altered by the fact that i use cl-postgres as a backend for cl-rdbms): cl-postgres can send down 4 kind of values to the database: - byte vectors - strings - local-time timestamps (this one is sleazy, see below why) - numbers (this one is sleazy too, because postgresql doesn't know about rationals and converting them to double float under the hood loses precision. i'm not happy about this but it's much more practical then signaling an error and forcing the caller to deal with this all around by doing the same)
if your value does not fit in any of these then you must convert it to string yourself before binding it, but it must be done in a higher abstraction layer where (sql) type information is available. an example to demonstrate it is local-time, where the lisp local-time value is used to represent three different db types (timestamp, date, time; where the latter two have constraints on various parts on the local-time value). if you don't care about asserts then you can just local-time:format-rfc3339-timestring the timestamp but it would silently drop information in case of programming errors (e.g. binding a local-time timestamp with non-utc timezone into an sql timestamp without timezone value. postgresql silently ignores the timezone info when doing this).
the relevant part of cl-rdbms that deals with this is in execute-postmodern-prepared-statement here: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-rdbms-cl-rdbms;a=h...
some tests dealing with syntax and types: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-rdbms-cl-rdbms;a=h...