+/* Win32 does not have UTF-8, so we need to map to UTF-16 */
I wonder if this is still true. I think in Windows 10+ you can enable
UTF-8 support. Then could you use strcoll_l() directly? I struggled
to understand that, but I am a simple Unix hobbit from the shire so I
dunno. (Perhaps the
Attached some new patches. I think you were right that the API of
pg_strcoll() was strange before, so I changed it to:
* pg_strcoll() takes nul-terminated arguments
* pg_strncoll() takes arguments and lengths
The new pg_strcoll()/pg_strncoll() api in 0001 seems much reasonable to
support in t
On Tue, 2022-11-01 at 13:36 +0100, Peter Eisentraut wrote:
> But I think putting the Windows UTF-8 code (win32_utf8_wcscoll())
> from
> varstr_cmp() into pg_strcoll() might create future complications.
> Normally, it would be up to varstr_sortsupport() to set up a
> Windows/UTF-8 specific compar
On 15.10.22 01:00, Jeff Davis wrote:
On Thu, 2022-10-13 at 10:57 +0200, Peter Eisentraut wrote:
It's a bit confusing that arguments must be NUL-terminated, but the
length is still specified. Maybe another sentence to explain that
would
be helpful.
Added a comment. It was a little frustrating
On Thu, 2022-10-13 at 10:57 +0200, Peter Eisentraut wrote:
> It's a bit confusing that arguments must be NUL-terminated, but the
> length is still specified. Maybe another sentence to explain that
> would
> be helpful.
Added a comment. It was a little frustrating to get a perfectly clean
API, b
On 07.10.22 01:15, Jeff Davis wrote:
+ * Call ucol_strcollUTF8(), ucol_strcoll(), strcoll(), strcoll_l(), wcscoll(),
+ * or wcscoll_l() as appropriate for the given locale, platform, and database
+ * encoding. Arguments must be NUL-terminated. If the locale is not specified,
+ * use the database
