On Fri, Jan 23, 2015 at 12:34 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> In other words, even on systems that don't HAVE_LOCALE_T, we still
> have to support the default collation and the C collation, and they
> have to behave differently. There's no way to make that work using
> only strxfrm(), because nothing gets passed to that function to tell
> it which of those two things it is supposed to do.
>
> Now even if the above were not an issue, for example because we
> dropped support for systems where !HAVE_LOCALE_T, I think it would be
> poor form to depend on strxfrm_l() to behave like memcpy() where we
> could just as easily call memcpy() and be *sure* that it was going to
> do what we wanted. Much of writing good code is figuring out what
> could go wrong and then figuring out how to prevent it, and relying on
> strxfrm_l() would be an unnecessary risk regardless. Given the
> existence of !HAVE_LOCALE_T systems, it's just plain broken.
Now that these issues are fixed and the buildfarm is green again, I'm
going to try re-enabling this optimization on Windows. My working
theory is that disabling that categorically was a mis-diagnosis of the
real problem, and that now that the issues mentioned above are cleaned
up, it'll just work. That might not be right, but I think it's worth
a try.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
