From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org> |
Subject: | Re: Path separator |
Date: | 2009-04-02 08:35:14 |
Message-ID: | 49D478C2.3050300@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> I've seen a couple of reports that the new SSL error messages on windows
>> look strange with paths the wrong way. For example:
>
>> root certificate file "C:\Documents and Settings\<SNIP>\Application
>> Data/postgresql/root.crt" does not exist.
>
>> The issue being the mix of forward and backwards slashes. Attached patch
>> should fix this.
>
>> Is this worth doing? Comments?
>
> In view of the way that canonicalize_path() works, I can't help thinking
> this is going in precisely the wrong direction.
In a way, yes. But canonicalize_path() runs only in the backend, and
this is only in the frontend. I think the requirements on the frontend
are slightly different than the backend.
But the most important thing is to be consistent within the same path as
we report it I think, so we could switch all to forward slashes as well
if you think that's better.
>
> Also, don't we already have a macro someplace for the platform's
> preferred path separator?
I looked for a macro for it, didn't find it. It seems to be hardcoded.
We have macros for SYSTEM_QUOTE for example, but not for the path
separator AFAICF.
I just realized we have a make_native_path() function, I had completely
missed that one. So we could possibly use that instead. In the end it
does the same thing
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2009-04-02 08:50:08 | Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. |
Previous Message | Magnus Hagander | 2009-04-02 08:18:25 | Re: "failed to commit client_encoding" explained |