Re: Correctly producing array literals for prepared statements

On Wed, Feb 23, 2011 at 03:34:45PM -0500, Andrew Chernow wrote:
> On 2/23/2011 3:06 PM, Peter Geoghegan wrote:
>> On 23 February 2011 15:34, Merlin Moncure<mmoncure@gmail.com>  wrote:
>>> You can send nested arrays safely.  You just have to be very formal
>>> about escaping *everything* both as you get it and as it goes into the
>>> container.  This is what postgres does on the backend as it sends
>>> arrays out the door in text.  It might be instructive to see what the
>>> server does in terms of escaping.  Note that the way this works it's
>>> not impossible to see 128+ consecutive backslashes when dealing with
>>> arrays of composites.
>>
>> Sounds tedious.
>>
>
> It is tedious, which is one reason why libpqtypes went binary.  There are 
> some compelling performance reasons as well that affect both client and 
> server.
>
> libpqtypes was originally developed to serve a very particular need and 
> wasn't aiming to be general purpose.  That came about along the way trying 
> to solve the problem.  Personally, PQexec is dead to me as well as text 
> results from a C/C++ app.  I see no advantage over libpqtypes in that 
> context.
>
> Unless I am missing your ultimate goal, you'd probably get what you want by 
> wrapping libpqtypes.
>

The performance is one of the big reasons to use binary parameters.
Converting/packing/transmitting/unpacking/converting use a lot of
CPU resources on both the server and the client in addition to 
the larger communication resources needed by the text-based methods.

Ken