BUG #15230: "Logical decoding" is not sensitive to client encodingsetting
От | PG Bug reporting form |
---|---|
Тема | BUG #15230: "Logical decoding" is not sensitive to client encodingsetting |
Дата | |
Msg-id | 152818735197.26724.16299315668820383342@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #15230: "Logical decoding" is not sensitive to clientencoding setting
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 15230 Logged by: Hillel Eilat Email address: hillel.eilat@attunity.com PostgreSQL version: 9.4.4 Operating system: Windows 7 Description: Logical Decoding is not sensitive to Client character encoding setting My project uses Logical Decoding by interacting with the WAL backend via native non-SQL interface. The plugin used is the common "test_decoding", which is shipped together with the kit. 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. Despite the above setting , data which is streamed in does not show up in UTF8. It preserves the backend server EUC_JP encoding. This must be a bug. One would expect that decoded data which is treamed in should be subjected to client encoding. Your assistance will be appreciated. Regards Hillel.
В списке pgsql-bugs по дате отправления: