Re: [HACKERS] Logical Replication and Character encoding
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] Logical Replication and Character encoding |
Дата | |
Msg-id | bcc7f7e9-f558-b19e-b544-000ba7cf286c@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Logical Replication and Character encoding (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Logical Replication and Character encoding
|
Список | pgsql-hackers |
On 01/02/17 04:05, Kyotaro HORIGUCHI wrote: > Hello, > > At Tue, 31 Jan 2017 12:46:18 +0000, "Shinoda, Noriyoshi" <noriyoshi.shinoda@hpe.com> wrote in <AT5PR84MB0084FAE5976D89CDE9733093EE4A0@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
В списке pgsql-hackers по дате отправления: