Re: PQescapeString handling of \0 - Mailing list pgsql-interfaces

From greg@turnstep.com
Subject Re: PQescapeString handling of \0
Date
Msg-id c4029001e28eb9350effc9118d391bc9@biglumber.com
Whole thread Raw
In response to Re: PQescapeString handling of \0  (Igor Shevchenko <igor@carcass.ath.cx>)
Responses Re: PQescapeString handling of \0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Tom Lane wrote:
> 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 ...

Igor Shevchenko replied:
> 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.

Has we reached a consensus on this? I'd like to have DBD::Pg and PQescapeString 
consistent. Right now, we (DBD::Pg) are leaning toward the "bail if we hit \0" 
theory, but it would be nice to have something definitive in the API.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200310030936

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE/fXvlvJuQZxSWSsgRAsc9AKDbn7QdDCk0lGDVP17249I0VbN9ygCg+BH4
UJxIs5PakXA0Mkth0td0jHw=
=KMEd
-----END PGP SIGNATURE-----




pgsql-interfaces by date:

Previous
From: Igor Shevchenko
Date:
Subject: Re: PQescapeString handling of \0
Next
From: Tom Lane
Date:
Subject: Re: PQescapeString handling of \0