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