* Jeff Davis:
> Agreed. Ultimately, the conversion has to be done somewhere, but I don't
> believe the driver is the place for it. Type conversions are always
> going to be imperfect, and this has some important consequences:
> * The type conversion system will be endlessly tweaked to improve it
> * Developers will always run into problems with it in any complex
> application, so we need to allow them to circumvent the system and do it
> themselves when necessary.
The downside is that passing strings up to the application may have
distinctly worse performance characteristics than passing a number.
> In ruby-pg, you can just do:
>
> conn.exec("INSERT INTO foo VALUES($1)", ["Jeff"])
>
> And I think that's appropriate. What I'm saying is that there should
> still exist some way to pass explicit types or formats (although that
> should still be easier than it is in C ;). Here's the long form:
>
> conn.exec("INSERT INTO foo VALUES($1)",
> [{:value => "Jeff", :format => 0, :type => 0}])
Okay, this isn't too bad an API. I will use the same approach. In my
case, it means no transparent support for arrays, but per your own
guidelines, this is okay.
> That copies value so that foo and bar have the same contents: a 4 byte
> value "\000". What would happen though, if val was transparently
> decoded? It would decode it once in ruby, and again inside of postgres
> (in byteain), leaving you with a one byte value in bar, even though foo
> has a four-byte value.
I've never viewed it from this angle, and I agree that it makes sense.
Thanks for your observations and explanations, they were helpful.
