* Jeff Davis:
> I have written up a set of guidelines for driver development based on
> what I learned working on ruby-pg:
>
> http://wiki.postgresql.org/wiki/Driver_development
Interesting, thanks.
I'm contemplating to create a new language binding for libpq (or, to
be more precise, turn an existing language binding into something that
can be published). I've been agonizing a bit over how to create a
bridge between the host language type system and the PostgreSQL type
system. If I understand you correctly, you suggest to leave
everything as strings. This solution has the appeal of being
implemented easily. It also sidesteps a lot of issues revolving
around different representation choices for numbers.
Do you really suggest to preserve the PQexecParams API verbatim, that
is, passing in three arrays containing type, value, and format? That
seems to be a bit problematic. I suspect the common case will be to
use unknown types, text format, and the default conversion from values
to strings. Only for BYTEA values, something else is required, and
I'm wondering how to encode that (the host language doesn't offer a
distinction between text and binary strings).
Conversely, for result sets, I'm tempted to transparently decode
escaped BYTEA columns.
> Note that the ruby-pg driver doesn't 100% adhere to those standards
> (encoding is the primary problem, and that will be fixed).
Lack of Unicode support means that I can punt that to application
authors, I guess.
By the way, the downside of using strings everywhere is that your
binding API will most likely not work with SQLite (or any other
SQL-like database which lacks column type information).
