Re: Bug with PATHs having non-ASCII characters - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Bug with PATHs having non-ASCII characters
Date
Msg-id 20100107180041.GF4315@alvh.no-ip.org
Whole thread Raw
In response to Re: Bug with PATHs having non-ASCII characters  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander wrote:
> On Thu, Jan 7, 2010 at 02:37, Takahiro Itagaki
> <itagaki.takahiro@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 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.
> 
> Shouldn't we develop this with "multi-platform" in mind from the
> start, instead of doing a Windows specific patch? It may be that we
> end up with two completely different codepaths, but more likely we can
> share some of it between them?

I'm not sure there's a lot you can do in platforms other than Windows.
On Windows the filenames are all Unicode and you know you can get them
using UTF16.  On other platforms it could be anything, and it is
certainly not server_encoding; even different filesystems can use
different encodings.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: Streaming replication and postmaster signaling
Next
From: "Kevin Grittner"
Date:
Subject: Re: Serializable Isolation without blocking