pg_dump 8.1.2 with 7.4.2 server screws up with LATIN1 strings

Поиск
Список
Период
Сортировка
От Marinos Yannikos
Тема pg_dump 8.1.2 with 7.4.2 server screws up with LATIN1 strings
Дата
Msg-id 444FFF6D.6070302@geizhals.at
обсуждение исходный текст
Список pgsql-bugs
I did this:

pg_dump -Fp -a -d -h <server> logdb -t fatlog > fatlog.txt

The output begins with:

SET client_encoding = 'LATIN1';
SET check_function_bodies = false;
SET client_min_messages = warning;

SET search_path = public, pg_catalog;

--
-- Data for Name: fatlog; Type: TABLE DATA; Schema: public; Owner: root
--

[...]

Now, whenever there is an "Umlaut" character in the strings, the output
looks like this:

INSERT INTO fatlog VALUES
(E'/redir.pl/onetwosold/a.asp?f=11&p1=Bilora%20Card%20Safe%20f\\xfcr%20SD%20Karten&p2=1',
'http://www.something.com/?such=Bilora+Card+Safe+f%FCr+SD+Karten',
'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)',
302, 352, NULL, 'GET', '127.0.0.1', '2006-04-24 18:12:08+02',
'127.0.0.1', '8001
', '123.123.123.123', 0, NULL, NULL);

The "\\xfc" in the output apparently causes pg_dump to write an "E"
before the string in the parentheses, causing the following error during
execution of the INSERT:

ERROR:  type "e" does not exist

I'm not sure whether the "\\xfc" sequence was in the database like this
before the dump, it may have been a LATIN1 character or the escape sequence.

Regards,
-mjy
--
Dipl.-Ing. Marinos Yannikos, CEO
Preisvergleich Internet Services AG
Obere Donaustrasse 63, A-1020 Wien
Tel./Fax: (+431) 5811609-52/-55

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #2406: Not all systems support SHM_SHARE_MMU
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: prepare-alter-exec issue