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. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
