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).  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.

Right. That's possible, but completely undocumented AFAICT. Also, I think
slony has some responsibility to prevent users from shooting themselves in
the foot.

Thanks,

Gavin