Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> It depends on tolower(), which is going to have LC_CTYPE-dependent
>>> behavior, which is surely wrong?
>
>> Or are you just saying we should be using pg_tolower()? (which I forgot
>> about yet again)
>
> Well, I'd be happier with pg_tolower, because I know what it does.
> But the real question here is what does "case insensitivity" on
> file names actually mean in Windows --- ie, what happens to non-ASCII
> letters?
The filesystem itself is UTF-16. I would assume the "system default"
locale controls the case insensitivity, but I'm not sure about that.
Reading up some, it seems the collation is actually stored in a hidden
file on the NTFS volume... It seems to differ between different versions
of windows from what I can tell, but since this is written to the fs,
it's ok.
I have not found a way to actually *get* the locale.. Or even to compare
two filenames. There is a function called GetFullPathName(), but I'm not
sure how to use it for this.
However. I don't think it's really critical that we deal with all corner
cases for this. It's not likely that the user would be using any really
weird locale-specific combinations *differently* in the PATH variable vs
the commandline, or something like that...
And this only shows up when the binary is found in the PATH and not
through a fully specified directory. This is, AFAICT, the only case
where they can differ. This is the reason why we haven't had any reports
of this before - nobody using the installer, or doing even a "normal
style" install would ever end up in this situation.
//Magnus
