Re: Differences in Escaped bytea's when creating a plain pg_dump
От | WR |
---|---|
Тема | Re: Differences in Escaped bytea's when creating a plain pg_dump |
Дата | |
Msg-id | bfeca831-49e1-41d5-66be-2af701b54162@freenet.de обсуждение исходный текст |
Ответ на | Differences in Escaped bytea's when creating a plain pg_dump (WR <wolle321@freenet.de>) |
Ответы |
Re: Differences in Escaped bytea's when creating a plain pg_dump
|
Список | pgsql-general |
Another strange thing is: in my first mail I wrote: running the dump in in pgadmin works, in the last mail I wrote pgadmin also produces the error. I played a little bit how this could be happend. Everytime ich used the following sql text in the querytool: SET standard_conforming_strings = on; INSERT INTO public.oned_figures VALUES (1, 'Figure_Wolle1', 476, -476, 2000, 2400, 2400, '\000', 500, 0, 'sinus(0|0|0;30;5;0;0,5;0)', '2021-08-31 11:53:22.442801', 0, 1); After each run I deleted the line with a View/Edit Data Panel of the Table. First run worked. Second run worked. Then I changed to SET standard_conforming_strings = off; Third run worked. Fourth run throw the error Then I changed back to SET standard_conforming_strings = on; Fifth run throw the error too. And only adding E and second backslash helped. I could reproduce this behavior everytime I close the query tool and opened it again. But this looks more like a pgadmin-bug. -- May the source be with you
В списке pgsql-general по дате отправления: