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(at)gmail(dot)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