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.rissler@freenet.de
mobil: +49 1520 9191759
- may the source be with you -
