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