From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | craig(at)2ndquadrant(dot)com, noriyoshi(dot)shinoda(at)hpe(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Logical Replication and Character encoding |
Date: | 2017-02-17 15:14:38 |
Message-ID: | e071fbfc-d7d7-e395-0210-1cbb5aa4071c@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/15/17 17:55, Petr Jelinek wrote:
> I am not quite convinced that this should be handled by logical decoding
> itself. It's quite possible to have output plugins that will handle this
> correctly for their use-cases (by doing similar conversion you did in
> the original patch) so they should not be prevented doing so.
> So it's probably better to check this in the plugin.
>
> I do like the idea of just using client_encoding in libpqrcv_connect though.
Well, it is sort of a libpq connection, and a proper libpq client should
set the client encoding, and a proper libpq server should do encoding
conversion accordingly. If we just play along with this, it all works
correctly.
Other output plugins are free to ignore the encoding settings (just like
libpq can send binary data in some cases).
The attached patch puts it all together.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-logical-replication-with-different-encodings.patch | text/x-patch | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-02-17 15:19:56 | Re: pg_recvlogical.c doesn't build with --disable-integer-datetimes |
Previous Message | Stephen Frost | 2017-02-17 15:02:19 | Re: Help text for pg_basebackup -R |