Tom Lane wrote:
> Ruzsinszky Attila <ruzsinszky(dot)attila(at)gmail(dot)com> writes:
>> The DB is the same except the character coding. Source is LATIN2 and
>> the target DB is UTF8.
>> We wrote a trigger to copy the data from source to target with dblink.
>> The problem is the
>> different DB character coding! PGSQL complains about wrong byte order.
> Hmm. You can presumably fix this by setting client_encoding in the
> dblink connection to match the encoding in use in the database it's
> called in. But I wonder why dblink doesn't just do that for you
Mainly because I never thought about it myself before, and this is the
first time I've seen someone complain ;-)
But if you think automatically setting client encoding is appropriate, I
will make the change. Would it be classified as a bug (and therefore
something to backpatch) or a new feature?
In response to
pgsql-novice by date
|Next:||From: Tom Lane||Date: 2009-02-03 15:22:19|
|Subject: Re: [NOVICE] LATIN2->UTF8 conversation with dblink |
|Previous:||From: Nikhil teltia||Date: 2009-02-02 23:35:52|
|Subject: Function Returning a Set of Composite Value|
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2009-02-03 03:00:10|
|Subject: Re: How to get SE-PostgreSQL acceptable|
|Previous:||From: Robert Haas||Date: 2009-02-03 02:26:24|
|Subject: Re: add_path optimization|