Tom Lane wrote: > Magnus Hagander <mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers