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).  My 
> thought on this brings us back to a point already stated and that is, by 
> allowing for this we end up with DB's that are not true data replicas of each 
> other.
> 

That's one point. The other is what is wrong with setting the env var 
PGCLIENTENCODING for slon? 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.

Seems to me that one slon can only use one and the same client encoding 
on all its connections. If it does that and the replication succeeds, 
then the subscriber is still a true replica of the origin. It might be 
that things break on a switchover, because the replica uses an encoding 
that is a superset of the origins, or things might fail further down the 
road when specific characters are used.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #