| 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: | 20100107103740.97A5.52131E4D@oss.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Chuck McDevitt <cmcdevitt(at)greenplum(dot)com> wrote:
> Just an FYI regarding this bug:
> http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php
>
> 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.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
| Attachment | Content-Type | Size |
|---|---|---|
| pgwin32_open.patch | application/octet-stream | 4.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-01-07 01:40:28 | Re: Testing with concurrent sessions |
| Previous Message | Robert Haas | 2010-01-07 01:15:13 | Re: Testing with concurrent sessions |