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