From: alex f <alex@...>
Date: 2002-09-04T02:02:34+09:00
Subject: DBI: sql types -> ruby types

Hi

I've been using dbi (thanks to the author) with Postgres and MySQL, and I've
run into a slightly frustrating (mis?)-feature. When a sql cell containing
NULL is selected using the MySQL dbd, the value is represented as Ruby nil
(which is what I would expect); but when using Pg, NULL comes back
represented as "" (the empty string - not what i'd expect).

There's also divergences when selecting, for example, an INT or FLOAT cell.
Here, MySQL returns a string with the value (eg "4"), whereas Pg gives me
back a Ruby Fixnum (4) or Float (4.0)- here postgres is nearer to what I'd
expect.

I'm aware that this is coming from the underlying ruby bindings clients
rather than the DBDs. I don't know any C, so there may be some restrictions
inherited from the different RDBMS client code that I'm missing. Still I'd
really appreciate any pointers on how best to work round this, as I'm
finding it a hindrance to the kind of portability that a dbi-layer aims to
provide.

I'd also really welcome any opinions on whether a DBD specification should
define ANSI SQL - Ruby Type mappings? What are folks' experience of this in
other languages? (I've only used the Perl DBI and some varyingly horrible
PHP db abstractions, neither of which has to confront type casting).

cheers
alex fenton
__