2009/10/13 Itagaki Takahiro :
>
> Magnus Hagander 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
Robert Haas wrote:
> > 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
On Mon, Oct 12, 2009 at 9:13 PM, Itagaki Takahiro
wrote:
>
> Magnus Hagander 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 kn
Magnus Hagander 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 r
Magnus Hagander writes:
> 2009/10/7 Itagaki Takahiro :
>> Also I added the following error checks before calling pgwin32_toUTF16()
>> (errordata_stack_depth < ERRORDATA_STACK_SIZE - 1)
>> to avoid recursive errors, but I'm not sure it is really meaningful.
>> Please remove or rewrite this part
2009/10/7 Itagaki Takahiro :
>
> Magnus Hagander wrote:
>> Per your own comments earlier, and in the code, what will happen if
>> pg_do_encoding_conversion() calls ereport()? Didn't you say we need a
>> non-throwing version of it?
>
> We are hard to use encoding conversion functions in logging rou
Magnus Hagander wrote:
> First of all, the change to port/open.c seems to be unrelated to the
> rest, and should be a separate patch, correct? I'm sure there's a
> usecase for it, but it's not actually included in the patches
> description, so I assume this was a mistake?
It was just a demo fo
2009/9/15 Itagaki Takahiro :
>
> Heikki Linnakangas wrote:
>
>> Can't we use MultiByteToWideChar() to convert directly to the required
>> encoding, avoiding the double conversion?
>
> Here is an updated version of the patch.
> I use direct conversion in pgwin32_toUTF16() if a corresponding codepag
On Tue, 2009-09-15 at 12:49 +0900, Itagaki Takahiro wrote:
> Here is an updated version of the patch.
This is a review of the Eventlog encoding on Windows patch:
http://archives.postgresql.org/message-id/20090915123243.9c59.52131...@oss.ntt.co.jp
Purpose & Format
This patch is de
Heikki Linnakangas wrote:
> Can't we use MultiByteToWideChar() to convert directly to the required
> encoding, avoiding the double conversion?
Here is an updated version of the patch.
I use direct conversion in pgwin32_toUTF16() if a corresponding codepage
is available. If not available, I stil
Itagaki Takahiro wrote:
> We can choose different encodings from platform-dependent one
> for database, but postgres writes serverlogs in the database encoding.
> As the result, serverlogs are filled with broken characters.
>
> The problem could occur on all platforms, however, there is a solution
We can choose different encodings from platform-dependent one
for database, but postgres writes serverlogs in the database encoding.
As the result, serverlogs are filled with broken characters.
The problem could occur on all platforms, however, there is a solution
for win32. Since Windows supports
* Tatsuo Ishii <[EMAIL PROTECTED]> [011010 18:21]:
> Receiving a request to add ISO 8859-15 and 16, I review the multibyte
> support code and found several errors in it.
>
> 1) There is a confusion between "LATIN5" and ISO 8859-5. LATIN5 is not
>ISO 8859-5, but is actually ISO 8859-9. Should
Tatsuo Ishii writes:
> BTW, should we support ISO 8859-6 and beyond for 7.2?
If possible we should. Otherwise people might spread the word that
PostgreSQL is not ready for the Euro.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end o
On Wed, Oct 10, 2001 at 03:40:25PM +0900, Tatsuo Ishii wrote:
> Receiving a request to add ISO 8859-15 and 16, I review the multibyte
> support code and found several errors in it.
>
> 1) There is a confusion between "LATIN5" and ISO 8859-5. LATIN5 is not
>ISO 8859-5, but is actually ISO 8859
> 1) There is a confusion between "LATIN5" and ISO 8859-5. LATIN5 is not
>ISO 8859-5, but is actually ISO 8859-9. Should we rename LATIN5 to
>"ISO8859-5" (or whatever) as the encoding name? I think we should.
>For your information, here are the correct mapping between ISO
>8859-n a
Receiving a request to add ISO 8859-15 and 16, I review the multibyte
support code and found several errors in it.
1) There is a confusion between "LATIN5" and ISO 8859-5. LATIN5 is not
ISO 8859-5, but is actually ISO 8859-9. Should we rename LATIN5 to
"ISO8859-5" (or whatever) as the encod
17 matches
Mail list logo
