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