Re: [HACKERS] Logical Replication and Character encoding - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Logical Replication and Character encoding
Date
Msg-id e071fbfc-d7d7-e395-0210-1cbb5aa4071c@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Logical Replication and Character encoding  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] Logical Replication and Character encoding
List 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Help text for pg_basebackup -R
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] pg_recvlogical.c doesn't build with--disable-integer-datetimes