Gavin Sherry wrote:
> On Thu, 8 Dec 2005, Jan Wieck wrote:
> 
> 
>>On 12/8/2005 11:46 AM, Darcy Buskermolen wrote:
>>
>>
>>>On Thursday 08 December 2005 07:49, Jan Wieck wrote:
>>>
>>>>On 12/8/2005 7:18 AM, Andrew Sullivan wrote:
>>>>
>>>>>On Thu, Dec 08, 2005 at 12:18:17AM +0100, Andreas Pflug wrote:
>>>>>
>>>>>>Whatever default is, manual override possibility is what I suggested. Do
>>>>>>you agree it should be configurable on the node level, not as slon cmd
>>>>>>line option?
>>>>>
>>>>>Seems like it'd have to be -- see Gavin's note in this thread.
>>>>
>>>>I am missing all the time what exactly the point is to have replicated
>>>>databases installed with different character encodings. Why are we
>>>>solving problems that do not exist unless someone deliberately screws up
>>>>the environment?
>>>>
>>>>Jan
>>>
>>>I think the point was to allow for a methood of "upgrading" allowing someone
>>>to upgrade from one encoding to another (but I may be off base here).  

Not only that. For example you might have replication from branch 
offices LATIN1 databases into you main UTF8 OLAP database.

>>>
>>
>>That's one point. The other is what is wrong with setting the env var
>>PGCLIENTENCODING for slon? 

Sounds as if this affects all connection a slon process creates? We're 
talking about *different* encodings.

If slon connects to a remote DB with a
>>specific client_encoding, the data it receives on FETCH is supposed to
>>be in exactly that enoding. That means it must connect to another
>>database (like it's local node DB) with exactly the same encoding,
>>because that is what the data it is sending is in.

Not necessarily. Quite often, LATIN1 or so is (mistakenly) stored in 
SQL_ASCII databases.

Regards,
Andreas