Hello Noah,
Thanks for your work, your patch is definitely better. I agree that this
approach much more generic.
23.06.2013 20:53, Noah Misch wrote:
> The attached revision fixes all above points. Would you look it over? The
> area was painfully light on comments, so I added some. I renamed
> pgwin32_toUTF16(), which ceases to be a good name now that it converts from
> message encoding, not database encoding. GetPlatformEncoding() became unused,
> so I removed it. (If we have cause reintroduce the exact same concept later,
> GetTTYEncoding() would name it more accurately.)
Yes, the patch works for me. I have just a little question about
pgwin32_message_to_UTF16. Do we need to convert SQL_ASCII through UTF8
or should SQL_ASCII be mapped to 20127 (US-ASCII (7-bit))?
> What should we do for the back branches, if anything? Fixes for garbled
> display on consoles and event logs are fair to back-patch, but users might be
> accustomed to the present situation for SQL_ASCII databases. Given the low
> incidence of complaints and the workaround of using logging_collector, I am
> inclined to put the whole thing in master only.
I thought that the change could be a first step to the PosgreSQL log
encoding normalization. Today the log may contain messages with
different encodings (we had a long discussion a year ago:
http://www.postgresql.org/message-id/5007C399.6000405@gmail.com)
Now the new function GetMessageEncoding allows to convert all the
messages consistently. If the future log encoding fix will be considered
as important enough to be backported, then this patch should be
backported too.
Thanks again!
Best regards,
Alexander