On 01/02/17 04:05, Kyotaro HORIGUCHI wrote: > Hello, > > At Tue, 31 Jan 2017 12:46:18 +0000, "Shinoda, Noriyoshi" > <noriyoshi.shin...@hpe.com> wrote in > <at5pr84mb0084fae5976d89cde9733093ee...@at5pr84mb0084.namprd84.prod.outlook.com> >> I tried a committed Logical Replication environment. I found >> that replication between databases of different encodings did >> not convert encodings in character type columns. Is this >> behavior correct? > > The output plugin for subscription is pgoutput and it currently > doesn't consider encoding but would easiliy be added if desired > encoding is informed. > > The easiest (but somewhat seems fragile) way I can guess is, > > - Subscriber connects with client_encoding specification and the > output plugin pgoutput decide whether it accepts the encoding > or not. If the subscriber doesn't, pgoutput send data without > conversion. >
Hmm I wonder if we should just make the subscriber send the client_encoding always (based on server encoding of the subscriber). That should solve the issue in combination with your patch no? -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
