Skip site navigation (1) Skip section navigation (2)

Re: Correctly producing array literals for prepared statements

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Correctly producing array literals for prepared statements
Date: 2011-02-23 20:34:45
Message-ID: 4D656F65.7040208@esilo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

-- 
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-02-23 20:45:20
Subject: Re: How to extract a value from a record using attnum or attname?
Previous:From: Alvaro HerreraDate: 2011-02-23 20:27:29
Subject: Re: Review: Fix snapshot taking inconsistencies

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group