Re: Correctly producing array literals for prepared statements

>
>
> 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/