Re: Fwd: Proper query implementation for Postgresql driver

Shay Rojansky <roji(at)roji(dot)org> writes:
> The idea of using extended query protocol for non-prepared queries raised
> another "best practices" question, which I'm hoping you can help with. To
> get rid of text encoding (which is locale-dependent, inefficient etc.) for
> certain fields, it seems that we have to get rid of it for *all* fields.
> This is because we send queries without knowing their result columns in
> advance, and would like to pack all messages into a single packet to avoid
> roundtrips.

FWIW, I'd go with text results, especially if you already have code to
deal with that. PG's on-the-wire binary formats are more efficient to
process in some absolute sense, but they're hardly free: you need to
consider byte endianness for integers and floats, integer vs float
encoding for timestamps, the difference between PG's timestamp
representation and whatever native timestamps are on your platform,
etc etc. It's not a trivial amount of code to deal with. And in the
end I think the efficiency gain is pretty marginal compared to the raw
costs of data transfer, especially if you're not on the same physical
machine as the server.

Binary formats are a good tradeoff for individual applications that know
exactly which data types they need to deal with. It's harder to make the
case that they're worth the trouble in general-purpose client libraries.

Having said that, there has been some talk of letting client libraries
supply a "whitelist" of data types that they'd like to receive in binary.
We could do that (modulo questions of whether it's worth incurring a
protocol version change for), but I'm unclear on what the use case really
is for that. Wouldn't you then have to provide an inconsistent API to
users of your driver, that is some things are presented in text and others
not? Is that really a great thing?

regards, tom lane