On 8/13/24 7:56 PM, Jeff Davis wrote:
> But I don't think that's a major problem -- we can just move the
> hardcoded test into pg_newlocale_from_collation() and return a
> predefined struct with collate_is_c/ctype_is_c already set.
I tried that out but thought it felt cleaner to do the hardcoding in
pg_set_regex_collation(). What do you think?
I have attached patches removing lc_collate_is_c() and lc_ctype_is_c().
I have not checked if there are any performance regressions when using
the C and POSIX locales but remove these special cases makes the code a
lot cleaner in my book.
I also attach some other clean up patches I did while touching this code.
0001-Remove-lc_collate_is_c.patch
Removes lc_collate_is_c().
0002-Remove-lc_ctype_is_c.patch
Removes lc_ctype_is_c() and POSIX_COLLATION_OID which is no longer
necessary.
0003-Remove-dubious-check-against-default-locale.patch
This patch removes a check against DEFAULT_COLLATION_OID which I thought
looked really dubious. Shouldn't this just be a simple check for if the
locale is deterministic? Since we know we have a valid locale that
should be enough, right?
0004-Do-not-check-both-for-collate_is_c-and-deterministic.patch
It is redundant to check both for "collation_is_c && deterministic", right?
0005-Remove-pg_collate_deterministic-and-check-field-dire.patch
Since after my patches we look a lot directly at the collation_is_c and
ctype_is_c fields I think the thin wrapper around the deterministic
field makes it seem like there is more to it so I suggest that we should
just remove it.
0006-Slightly-refactor-varstr_sortsupport-to-improve-read.patch
Small refactor to make a hard to read function a bit easier to read.
Andreas