Re: BUG #15230: "Logical decoding" is not sensitive to clientencoding setting
От | Euler Taveira |
---|---|
Тема | Re: BUG #15230: "Logical decoding" is not sensitive to clientencoding setting |
Дата | |
Msg-id | CAHE3wghOn4X2qQk7W+__ZMH8=jGJ81fCQb32xPNhYaELWCdppg@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #15230: "Logical decoding" is not sensitive to client encodingsetting (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
RE: BUG #15230: "Logical decoding" is not sensitive to clientencoding setting
|
Список | pgsql-bugs |
2018-06-05 5:29 GMT-03:00 PG Bug reporting form <noreply@postgresql.org>: > The plugin used is the common "test_decoding", which is shipped together > with the kit. > What is the test_decoding output mode? By default, it uses textual mode. Did you set binary mode (foce-binary=1)? > There is a Japanese database for which encoding is defined as ""EUC_JP". > Ordinarily - we process the streamed data in UTF8 client encoding - thus > maintaining a common general "consumer" functions. > Consequently, prior to issuing PQconnectdbParams(keywords, values, true) - a > {"client_encoding","UTF8"} couple is introduced. > To be on the safe side - a couple of PQclientEncoding(pConn) / > pg_encoding_to_char(iClientEncoding) is issued thereafter, > for approving that UTF8 was properly set. > client_encoding should be set in the replication connection because if you set it later it won't be passed down to libpqwalreceiver. [1] https://www.postgresql.org/docs/9.4/static/logicaldecoding-output-plugin.html#LOGICALDECODING-OUTPUT-MODE -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
В списке pgsql-bugs по дате отправления: