On Thu, Feb 14, 2013 at 11:11:13AM +0400, Alexander Law wrote:
> Hello,
>>>>> Alexander Law <exclusion@gmail.com> writes:
>>>>>> Please look at the following l10n bug:
>>>>>> http://www.postgresql.org/message-id/502A26F1.6010109@gmail.com
>>>>>> and the proposed patch.
>> With your proposed change, the problem will resurface in an actual SQL_ASCII
>> database. At the problem's root is write_console()'s assumption that messages
>> are in the database encoding. pg_bind_textdomain_codeset() tries to make that
>> so, but it only works for encodings with a pg_enc2gettext_tbl entry. That
>> excludes SQL_ASCII, MULE_INTERNAL, and others. write_console() needs to
>> behave differently in such cases.
> Thank you for the notice. So it seems that "DatabaseEncoding" variable
> alone can't present a database encoding (for communication with a
> client) and current process messages encoding (for logging messages) at
> once. There should be another variable, something like
> CurrentProcessEncoding, that will be set to OS encoding at start and can
> be changed to encoding of a connected database (if
> bind_textdomain_codeset succeeded).
I'd call it MessageEncoding unless it corresponds with similar rigor to a
broader concept.
>> On Tue, Feb 12, 2013 at 03:22:17AM +0000, Greg Stark wrote:
>>> >But that said I'm not sure saying the whole file is in an encoding is
>>> >the right approach. Paths are actually binary strings. any encoding is
>>> >purely for display purposes anyways.
>> For Unix, yes. On Windows, they're ultimately UTF16 strings; some system APIs
>> accept paths in the Windows ANSI code page and convert to UTF16 internally.
>> Nonetheless, good point.
> Yes, and if postresql.conf not going to be UTF16 encoded, it seems
> natural to use ANSI code page on Windows to write such paths in it.
> So the paths should be written in OS encoding, which is accepted by OS
> functions, such as fopen. (This is what we have now.)
To the contrary, we would do better to use _wfopen() after converting from the
encoding at hand to UTF16. We should have the goal of removing our dependence
on the Windows ANSI code page, not tightening our bonds thereto. As long as
PostgreSQL uses fopen() on Windows, it will remain possible to create a file
that PostgreSQL cannot open. Making the full transition is probably a big
job, and we don't need to get there in one patch. Try, however, to avoid
patch designs that increase the distance left to cover.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
