* 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.

In response to

• Re: Confusion over Python drivers at 2010-02-08 20:38:40 from Jeff Davis

Responses

• Re: Confusion over Python drivers at 2010-02-16 03:48:32 from Jeff Davis

pgsql-hackers by date

Next:	From: Peter Eisentraut	Date: 2010-02-14 20:02:00
	Subject: Re: Streaming Replication docs
Previous:	From: Tom Lane	Date: 2010-02-14 18:47:41
	Subject: Re: Listen / Notify - what to do when the queue is full