On Tue, 2008-04-08 at 13:08 -0400, Andrew Dunstan wrote:
> I think you should conduct a wider survey before you make that decision.
> In particular, I'd like to hear from driver writers like Greg Sabino
> Mullane and Jeff Davis, as well as regular libpq users.
>
I looked into this today.
* Arrays and composites
Better ability in libpq to parse and construct arrays and composites
would be helpful. I think this is worthwhile to consider, and I would
expose the functionality (at least for arrays) in ruby-pg if available.
* Binary formatting
The exclusive use of binary formats is worrisome to me. This circumvents
one level of indirection that we have (i.e. that everything moves
through in/out functions), and will impose a backwards-compatibility
requirement on the internal representation of data types, including
user-defined data types. As far as I know, we currently have no such
requirement, even for built-in types.
* Type conversion callbacks
The type conversion hooks make some sense, but I have reservations about
that policy as well. The data types in PostgreSQL will never match
perfectly the data types in a host language -- NULL in particular
doesn't have a direct counterpart.
If there were a perfect mapping of types, it would seem like a much
better idea. The problem is that we don't want to have some types that
are perfectly mapped (e.g. int, bytea), some that are imperfectly mapped
(e.g. dates, numeric), and some types that have no conversion defined
and fall back to something else. In this case, the result format is
always binary, so we can't even fall back to text.
In my experience trying to implicitly map to types doesn't save a lot of
time for the developer. You end up spending time referencing the
documentation (or some other part of the code) to figure out how the
edge cases are being handled rather than just handling them explicitly
in the code. For instance, wrapping a value you expect to be a date in
Date.parse() is more readable in most cases.
Regards,Jeff Davis
