From: Florian Weimer <fw@deneb.enyo.de>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Karthik Segpi <karthik.segpi@gmail.com>,  pgsql-interfaces@postgresql.org
Subject: Re: PQunescapebytea not reverse of PQescapebytea?
References: 
 <CACD7L9GCLsM=wEwwH707sN19dMkMHwHh+ffVmLQdsFXNR0UJ6Q@mail.gmail.com>
	<87bnx20w88.fsf@mid.deneb.enyo.de> <1395807598.2224.11.camel@jdavis>
Date: Sun, 18 Sep 2016 16:02:32 +0200
In-Reply-To: <1395807598.2224.11.camel@jdavis> (Jeff Davis's message of "Tue,
	25 Mar 2014 21:19:58 -0700")
Message-ID: <878tup1f2f.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-interfaces-owner@postgresql.org

* Jeff Davis:

> On Wed, 2014-03-19 at 21:28 +0100, Florian Weimer wrote:
>> * Karthik Segpi:
>>=20
>> > I have a 'bytea' column in the database, onto which my custom C applic=
ation
>> > is inserting encrypted data. Before inserting, I am calling
>> > 'PQescapebytea()' to escape the ciphertext. However, after SELECT, the=
 data
>> > needs to be 'un-escaped' before attempting to decrypt. I am trying to
>> > 'un-escape' using 'PQunescapebytea'. However, I am finding that
>> > 'PQunescapebytea' is not  exact inverse of 'PQescapebytea'. I saw
>> > documentation and posts in the mailing lists alluding to this as well.=
 As a
>> > result, the decryption always fails.
>>=20
>> Can you show us some example data that shows the inconsistency?
>> PQunescapebytea should give you back the blob you passed to
>> PQescapebytea, but the same blob can have different BYTEA
>> encodings=E2=80=94not everyone uses the \x hexadecimal encoding.
>
> Example:
>
>   size_t len1, len2;
>   char *str =3D "\\\\123";
>
>   printf("%s\n", str);
>   printf("%s\n", PQescapeBytea(str, strlen(str), &len1));
>   printf("%s\n", PQunescapeBytea(
>                                  PQescapeBytea(str, strlen(str), &len1),
>                                  &len2));
>
> The reason for this is that PQescapeBytea is designed to escape it to be
> passed into the server via a SQL string (adding two levels of escaping,
> one for the sql string and one for bytea); whereas PQunescapeBytea is
> designed to unescape a result coming back from the server (which only
> has one level of escaping to undo: the bytea escaping).

Ah, right, this is annoying.  I think a thin (one-level) escaping
function would make sense to add to libpq.


--=20
Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces