Re: Differences in Escaped bytea's when creating a plain pg_dump

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "WR" <wolle321(at)freenet(dot)de>
Cc: "pgsql-general" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Differences in Escaped bytea's when creating a plain pg_dump
Date: 2022-06-23 21:14:27
Message-ID: 488f2958-2417-4086-b138-eafb22e0a3f7@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

WR wrote:

> But one question is left.
>
> When I read this valid data into a c++ std::string (and I checked that
> the single backslashes are still there). Why can't I put this
> SQL-command to a pqxx-transaction and execute it. It looks like the
> pqxx-transaction unescapes the bytea-string and then it finds the 0x00
> bytes, which are not allowed in text-strings but should be in bytea-strings.

You may check your server logs. They would have the error messages
with the queries as received by the server.

Note that passing '\000'::bytea with a single backslash can be
incorrect if standard_conforming_strings if set to off (not
recommended since version 8.1).
In that case the backslashes need to be doubled.

Example:

postgres=# set standard_conforming_strings to off;
SET

postgres=# set escape_string_warning to off;
SET

postgres=# select '\000'::bytea;
ERROR: invalid byte sequence for encoding "UTF8": 0x00

postgres=# select '\\000'::bytea;
bytea
-------
\x00
(1 row)

There might also be a problem with how the string is being fed with
the C++ code, but you'd need to show us the code to get feedback
on it.

Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Masahiko Sawada 2022-06-24 02:39:28 Re: Support logical replication of DDLs
Previous Message Adrian Klaver 2022-06-23 18:21:21 Re: ERROR: new collation (en_US.UTF-8) is incompatible with the collation of the template database (en_US.utf-8)