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.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. I doubt that would prove to be back-patch material. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
