Re: PQunescapebytea not reverse of PQescapebytea?
От | Florian Weimer |
---|---|
Тема | Re: PQunescapebytea not reverse of PQescapebytea? |
Дата | |
Msg-id | 878tup1f2f.fsf@mid.deneb.enyo.de обсуждение исходный текст |
Ответ на | Re: PQunescapebytea not reverse of PQescapebytea? (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-interfaces |
* 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.
В списке pgsql-interfaces по дате отправления: