Andreas Pflug wrote:
> Gavin Sherry wrote:
> 
>> 
>> Slony can utilise this by setting the client encoding to the
>> encoding of the server it is working on. The problem should go away
>> then.
> 
> 
> IMHO slony should behave as a unicode application, i.e. use UTF8
> client encoding for all database connections. This will have pgsql
> apply conversions transparently, because most server encodings can
> convert happily from and to UTF8. The exception is SQL_ASCII and
> MULE_INTERNAL, in these cases client encoding must match server
> encoding, hoping that data will be stored correctly. pgAdmin runs
> correctly with this scheme.

Thinking a little more about this, non-standard encoding issues don't
seem to be covered by any implicit encoding selection. There are
probably many databases out there, that contain characters in a
different encoding than the db encoding reflects. Imagine a master
database with encoding SQL_ASCII containing LATIN1 (a common beginners
mistake, I took it myself back then) you'd like to transfer to a LATIN1
or Unicode database. Or worse, LATIN15 data in a LATIN1 encoded DB. This 
would require manually assigned client encodings.
Actually, all slon processes connecting to a specific node should always
use the same encoding on that connection, so I'd propose a
sl_node.no_encoding column that may contain NULL to indicate slon to use
an automatically selected client encoding, or the client encoding to use.

Regards,
Andreas