>
>
> It's probably fine if you can control both ends. But there is no
> guarantee of portability, nor does it seem likely to me there ever will
> be, so I don't find your assertion terribly useful. The fact that it
> hasn't broken for you doesn't mean it can't or won't be.
>
All true. If you change the protocol, libpqtypes needs to be adjusted. I think that is a very fair statement. It
alreadytoggles on server
version around a few changes in the past ... like the money data type.
So far, since 8.1, the number of changes to the binary protocol has put
me to sleep :)
> The other downside I see is that binary protocols are often a lot harder
> to debug, but maybe that's just me.
>
Also very true. However, libpqtypes addresses this by abstracting the
end user from the binary transformation or preparation. Instead, users
are presented with a printf/scanf style interface. PQexecf(conn,
"select %int4 + %int4", 4, 4) is pretty far removed from the underlying
byte swapping, parallel array setup for PQexecParams and other
nastiness. But yes, the maintainer of the library must deal with
protocol changes and provide backward compatibility.
--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/
