Re: BUG #7493: Postmaster messages unreadable in a Windows console

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