Re: prepared statement API proposal

Cyrus Harmon wrote:
> Exactly. My point was that postgres, and I assume other dbmses, have a 
> text encoding for binary data so that one can do a select and get back 
> properly escaped ASCII text that represents the binary data, at the 
> cost of increased size, time to decode, etc...

MySQL has a function to escape binary data going into a database, but
not out. However, it not sufficiently "escaped" so that SBCL fails on
the bytes stuffed into the string.

> Hmm... Yes, the :result-types thing works for me too, but I'm thinking 
> about arbitrary tables where we don't necessarily know the columns. One 
> of the odd but interesting things about the result types is that they 
> are either a list of types (or :auto) or just :auto. I'm interested in 
> supporting the (:auto :auto ...) and :auto cases in addition to 
> explicitly saying that a column is of type :blob. I suppose one could 
> use some thing like :auto-binary as a keyword for type to try to get 
> the args to the right place.

:auto support would be good. Unfortunately, it seems like the two most
popular database backends for CLSQL do not provide a way to know if a
field is declared to store binary data.

> In the postgres case, that's neither here nor there. I guess I'm being 
> thinking too closely along the lines of the postgresql API to make 
> clear what the problem is. In pgsqlv7.4 when you call the exec prepared 
> statement interface, you have a choice of binary or text encoding for 
> the results (note that this is for the entire result set, not an a per 

This is somewhat similar to MySQL 4.1 bind parameters which use binary
coding for all objects. However, I've not yet gotten CLSQL supporting
this correctly yet -- the API is rather tricky here.

> Thanks for helping me think this stuff through,

Glad to.

-- 
Kevin Rosenberg
kevin-HJRc7zDS/[email protected]