From: Igor Shevchenko <igor@carcass.ath.cx>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: PQescapeString handling of \0
Date: Mon, 29 Sep 2003 22:15:20 +0300
User-Agent: KMail/1.5.2
References: <200309291949.26188.igor@carcass.ath.cx>
	<27075.1064859721@sss.pgh.pa.us>
In-Reply-To: <27075.1064859721@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200309292215.20949.igor@carcass.ath.cx>
X-WIND.UKR.NET-ID: cff87da1949b8c7c2f242569bcb0eb60
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200309/71
X-Sequence-Number: 4489

If the purpose of PQescapeString is to make a safe variant of a given string 
(NULL-terminated or counted), where safity means ability to simply add it to 
the query (which is char* and is passed directly to PQexec), then either 
length should return what strlen would return for the given string or \0 
should be escaped somehow.

On Monday 29 September 2003 21:22, Tom Lane wrote:
> Igor Shevchenko <igor@carcass.ath.cx> writes:
> > Here's a patch which makes PQescapeString stop escaping when \0 is seen.
>
> Hm.  Is that really the right behavior?  Given that the function is
> defined to take a counted string rather than a null-terminated string,
> I'd sort of expect it to turn \0 into "\000" or some such.  Of course,
> given that this could overflow the specified size of the return buffer,
> one might simply conclude that the defined API is broken ...
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html

-- 
Best regards,
Igor Shevchenko