Re: Encoding issues in console and eventlog on win32

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Encoding issues in console and eventlog on win32
Date: 2009-10-17 00:24:57
Message-ID: 9837222c0910161724w3ad61752v90fa7668b6676a38@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/10/13 Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>:
>
> Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
>> One other question - you note that WriteConsoleW() "could fail if
>> stderr is redirected". Are you saying that it will always fail when
>> stderr is redirected, or only sometimes? If ony sometimes, do you know
>> under which conditions it happens?
>
> It will always fail if redirected. We can test the conditions using:
>    pg_ctl start > result.log
> So, the comment should be:
>    /* WriteConsoleW always fails if stderr is redirected. */

Ok, fair enough. We already have a variable for that though - it's
called redirection_done. I think it does what's necessary - I have
used that one in my version of the patch. Please verify that it works
in your environment.

> I cleaned up the patch per comments. I hope this will be the final one ;-).
>
>  * Use in_error_recursion_trouble() instead of own implementation.
>  * Use def_enc2name() macro to avoid adding the codepage field
>    on non-win32 platforms.

Per previous email, I had done this in my version of the patch, so it
looks slightly different than yours, but it has the same
functionality.

>  * Fix a bug of calculation of result length.

Where exactly is this one? I can't find it compared to my code, but
that could just be out-of-timezone-brain speaking :-)

>  * Fix a memory leak on error handling path in pgwin32_toUTF16().

Missed that one, thanks!

>> If it's always, I assume this just means that the logfile will be in
>> the database encoding and not in UTF16? Is this what we want, or would
>> we like the logfile to also be in UTF16? If we can convert it to
>> UTF16, that would fix the case when you have different databases in
>> different encodings, wouldn't it? (Even if your editor, unlike the
>> console subsystem, can view the individual encoding you need, I bet it
>> can't deal with multiple encodings in the same file)
>
> Sure, the logfile will be filled with mixed encoding strings,
> that could happen in logfile and syslog on non-win32 platforms.
> I think UTF8 is better than UTF16 for logfile encoding because
> there are some text editors that do not support wide characters.

Don't most text editors on Windows do UTF16? In particular, I'd expect
more of them to do UTF16 than UTF8, but I could be wrong?

> At any rate, the logfile encoding feature will come from another patch,
> that might add "log_encoding" variable and work on any platforms.

Ok, good. Particularly the "other platform" is the winning argument.

So, what I believe is the latest version of the patch applied. Please
point out if I made a mistake in my changes against yours.

Sorry about the delay :(

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-10-17 01:23:12 Re: Deprecation
Previous Message Jeff Davis 2009-10-16 20:35:47 Re: [HACKERS] contrib/plantuner - enable PostgreSQL planner hints