> 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 already toggles 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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-02-23 21:20:54|
|Subject: Re: Binary in/out for aclitem |
|Previous:||From: Kenneth Marshall||Date: 2011-02-23 21:01:54|
|Subject: Re: Correctly producing array literals for preparedstatements|