On Mon, Jun 24, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> 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))?
Good question. SQL_ASCII is an awkward database encoding; it actually
indicates ignorance about the significance of byte sequences in text. As a
result, nothing we do here is likely to be delightful. I caused an error
containing some LATIN2 bytes (SELECT * FROM "śmiać się") in an SQL_ASCII /
LC_CTYPE=C database, and the result was decent, considering: the event log
shows a question-mark-in-rhombus symbol for each of the non-ASCII bytes.
Using CP20127 turned it into "6miaf sij". I don't have a great idea for
improving on the existing hack.
>> 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.
I doubt that would prove to be back-patch material.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
