This is a discussion on pg_dump 8.1.2 with 7.4.2 server screws up with LATIN1 strings within the pgsql Bugs forums, part of the PostgreSQL category; --> I did this: pg_dump -Fp -a -d -h <server> logdb -t fatlog > fatlog.txt The output begins with: SET ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |