On Thu, Jan 7, 2010 at 02:37, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Chuck McDevitt cmcdev...@greenplum.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
Magnus Hagander wrote:
On Thu, Jan 7, 2010 at 02:37, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
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
Just an FYI regarding this bug:
http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php
Windows always uses UNICODE to store file and directory names.
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
Chuck McDevitt cmcdev...@greenplum.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
On Thu, Jan 7, 2010 at 12:57 AM, Chuck McDevitt cmcdev...@greenplum.com wrote:
Windows always uses UNICODE to store file and directory names.
So what does that mean when the filesystem is a shared filesystem or
one mounted in Windows but originally written out by another OS?
I think the answer
