Re: Win32 unicode vs ICU

.. back home again after a couple of days ..

<snip>
> >> I am unsure of how to proceed. As I see it there are three paths:
> >> 1) Use native win32 functionality only on win32
> >> 2) Use ICU functionality only on win32
> >> 3) Allow both ICU and native functionality, compile time
> >> switch --with-icu (same as unix with the ICU patch)
<snip>

> I feel it makes sense to apply the smaller patch in any case,
> so that there's a Win32 solution not requiring ICU (ie, I
> can't see an argument for doing (2) rather than (3)).
>
> Comments?

Sounds reasonable to me - couldn't really find a reasonable argument for
(2), but it was an option :-)

Though as it seems to be needed on FreeBSD as well, we should definitly
look at (3) as a long-term option. Considering Palle has been running it
in production for quite a while now IIRC, the ICU part should be fairly
stable. but see below...

> > And anohter question - my native patch touches the same
> functions as
> > the ICU patch. Can somebody who knows the internals confirm or deny
> > that these are all the required locations, or do we need to modify
> > more?
>
> There is a strxfrm() call in
> src/backend/utils/adt/selfuncs.c, which probably needs to be
> looked at too.

Ok. Will look into that. Do you have a hint as to how to test that?
Considering I've been unable to show incorrect function without donig
it, and apparantly so has Palle (with the ICU patch) running it in
production for a long time, I clearly don't know how to provoke a
failure with the current code.

Which brings up another point - there are clearly no regression tests
for this (considering we missed the unicode stuff early in the 8.0
cycle). Is there a reasonable way to add something along this line that
could be used, or will that be too complex? (I guess we can never test
completely as it depends on the OS locale handling, but some?) I'm
thinking it might be too complex as we'd need a new initdb with a
different encoding, but perhaps it's worth it anyway?

//Magnus