Skip site navigation (1) Skip section navigation (2)

Re: Bug with PATHs having non-ASCII characters

From: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Chuck McDevitt <cmcdevitt(at)greenplum(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug with PATHs having non-ASCII characters
Date: 2010-01-07 01:37:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Chuck McDevitt <cmcdevitt(at)greenplum(dot)com> wrote:

> Just an FYI regarding this bug:
> The wide-char version of any WIN32 API call will accept or return
> data in UTF-16 encoded Unicode, regardless of the local environment's
> single-byte (MBCS) encoding settings (codepage).

I have a Windows-specific patch for open(), attached for reference.
But we need to consider about other issues:

  - We need to consider about not only only open(), but also opendir(),
    stat() and symlink().

  - An entirely-different fix is needed for non-Windows platforms.
    Probably we will convert encodings from GetDatabaseEncoding() to
    GetPlatformEncoding() in MBCS, but this is not needed on Windows.
    We should consider avoiding random ifdef blocks for the switching.

  - Those conversions are not free. We might need to avoid conversions
    for paths under $PGDATA because we only use ascii names in the server.
    I used a test with IS_HIGHBIT_SET in the attached patch, but I'm not
    sure whether it is the best method.

Takahiro Itagaki
NTT Open Source Software Center

Attachment: pgwin32_open.patch
Description: application/octet-stream (4.4 KB)

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-01-07 01:40:28
Subject: Re: Testing with concurrent sessions
Previous:From: Robert HaasDate: 2010-01-07 01:15:13
Subject: Re: Testing with concurrent sessions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group