Re: tiny step toward threading: reduce dependence on setlocale()

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