Joe Conway <m...@joeconway.com> writes: > I think the attached is what you had in mind. But I don't know right off > how to trigger the failure (and therefore how to test the solution). A > naive test with two databases, one LATIN2, the other UTF8 does not > produce the error with simple text literals.
I can reproduce an error (and verify the patch corrects it) using this test case: select 'àx÷y'::text as x; select * from dblink('dbname = u8', $$select 'àx÷y'::text$$) as t1 (x text); (The two non-ASCII characters are octal 340 and 367, if they don't come through properly in your mail.) Execute in a LATIN1 database (being sure client_encoding is also LATIN1), connecting to a database with encoding UTF8. With the patch, both commands give the same results; without, I get ERROR: invalid byte sequence for encoding "UTF8": 0xe078f7 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". CONTEXT: Error occurred on dblink connection named "unnamed": could not execute query. Please get this committed soon, we have other stuff to get done (like a pgindent run). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers