On Fri, Jan 23, 2015 at 12:34 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
