Hello,
15.02.2013 02:59, Noah Misch wrote:
>>> With your proposed change, the problem will resurface in an actual SQL_ASCII
>>> database. At the problem's root is write_console()'s assumption that messages
>>> are in the database encoding. pg_bind_textdomain_codeset() tries to make that
>>> so, but it only works for encodings with a pg_enc2gettext_tbl entry. That
>>> excludes SQL_ASCII, MULE_INTERNAL, and others. write_console() needs to
>>> behave differently in such cases.
>> Thank you for the notice. So it seems that "DatabaseEncoding" variable
>> alone can't present a database encoding (for communication with a
>> client) and current process messages encoding (for logging messages) at
>> once. There should be another variable, something like
>> CurrentProcessEncoding, that will be set to OS encoding at start and can
>> be changed to encoding of a connected database (if
>> bind_textdomain_codeset succeeded).
> I'd call it MessageEncoding unless it corresponds with similar rigor to a
> broader concept.
Please look at the next version of the patch.
Thanks,
Alexander