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

Am 27.06.2022 um 09:32 schrieb David G. Johnston:

[snip]

> I suggest doing self-contained examples that demonstrate the documented
> behavior not working as documented (or not being functional even if
> intended) to pinpoint any bug that might be lurking here.  With only
> fragments and statements that seem impossible we are left to assume
> operator error.  pg_dump is completely correct in what it is producing
> (non-escape literal \000).
>
> I also suggest using psql and pg_dump directly, and not pgAdmin, to
> demonstrate a core PostgreSQL bug.
>
> David J.
>

Thank you David,
I followed you advice, using pg_dump and psql directly. And the in in
contrast to pgAdmin psql works like expected and reproducable again and
again.
With
SET standard_conforming_strings = on;

an INSERT without E and double backslash works.

SET standard_conforming_strings = off;

I get the warning and the error. So there is no core PostgreSQL bug, I
think.

PgAdmin has different result, when running the same sql commands
repeatedly. Before filing a bug there, I should update to the actual
release.

Now I will test our c++ code and will hopefully find out, why I can't
run the dump from a sql-file (where is SET standard_conforming_strings =
on;) as a pqxx-transaction...

--

Wolfgang Rißler
mailto: wolfgang(dot)rissler(at)freenet(dot)de
mobil: +49 1520 9191759
- may the source be with you -