On Mon, Oct 12, 2009 at 9:13 PM, Itagaki Takahiro <itagaki.takah...@oss.ntt.co.jp> wrote: > > Magnus Hagander <mag...@hagander.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. */ > > 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. > * Fix a bug of calculation of result length. > * Fix a memory leak on error handling path in pgwin32_toUTF16(). > > >> 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. > At any rate, the logfile encoding feature will come from another patch, > that might add "log_encoding" variable and work on any platforms.
Magnus has promised me on a stack of instant messages that he will review this soon, but as he hasn't gotten to it yet, I am moving it to the next CommitFest. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
