On Wed, 7 Dec 2005 cbbrowne at ca.afilias.info 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?
>
> I'm not certain what the right answer to that is.  (I don't have call to
> use these encodings, so I haven't got the experience to have a meaningful
> preference...)

I think that this is only an issue when the upstream database is
SQL_ASCII, MULE_INTERNAL or another encoding which accepts any character
sequence as valid. If the upstream is LATIN1 and the downstream is UTF8,
then PostgreSQL can be made to do the translation for us. If we don't
translate the characters, we wont even be able to insert the data into the
downstream database. So, I guess the issue is only about handling
SQL_ASCII et al.

>
> I could see there being multiple answers to this; it seems a mistake to me
> to leap to one answer immediately.
>
> I could see this being controlled several ways:
>
> 1.  Via a sl_node option which requests translation for all tables on a
> given node
>
> 2.  Via a slon option which controls this at runtime
>
> 3.  Via an sl_table option which requests translation for a specific table
> - though that's not enough to specify behaviour on specific nodes...
>
> 4.  Maybe we have to manage it at the column level; a mechanism isn't
> leaping to mind

We can't do 4. PostgreSQL doesn't support even table level character
encoding so, IMHO, it's a non-issue. I also think that option 2 is
fragile. Option 1 seems best.

> Ultimately, it's columns that have to be changed, which will decidedly
> affect the COPY in SUBSCRIBE_SET.
>
> I'll bet that's not yet all of the important details, and that we'll need
> more in order to assess what is an answer.

I'm going to look at a patch for now which does encoding conversions for
source character sets other than SQL_ASCII and MULE_INTERNAL. I'm going to
throw an error if the source database is SQL_ASCII/MULI_INTERNAL and the
destination database is not the same.

Gavin