* 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). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
