* Jeff Davis:
> On Wed, 2014-03-19 at 21:28 +0100, Florian Weimer wrote:
>> * Karthik Segpi:
>>
>> > I have a 'bytea' column in the database, onto which my custom C application
>> > 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.
>>
>> 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—not everyone uses the \x hexadecimal encoding.
>
> Example:
>
> size_t len1, len2;
> char *str = "\\\\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.
