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.6000...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
