Re: fixing tsearch locale support

I have expanded this patch set. The first three patches are the same as
before. I have added a new patch that gets rid of lowerstr() from
ts_locale.c and replaces it with the standard str_tolower() that
everyone else is using.

lowerstr() and lowerstr_with_len() in ts_locale.c do the same thing as
str_tolower(), except that the former don't use the common locale
provider framework but instead use the global libc locale settings.

This patch replaces uses of lowerstr*() with str_tolower(...,
DEFAULT_COLLATION_OID). For instances that use a libc locale globally,
this will result in exactly the same behavior. For instances that use
other locale providers, you now get consistent behavior and are no
longer dependent on the libc locale settings.

Most uses of these functions are for processing dictionary and
configuration files. In those cases, using the default collation seems
appropriate. At least we don't have a more specific collation
available. But the code in contrib/pg_trgm should really depend on the
collation of the columns being processed. This is not done here, this
can be done in a separate patch.

(You can probably construct some edge cases where this change would
create some locale-related upgrade incompatibility, for example if
before you used a combination of ICU and a differently-behaving libc
locale. We can document this in the release notes, but I don't think
there is anything more we can do about this.)

After these patches, the only problematic things left in ts_locale.{c,h} are

extern int t_isalpha(const char *ptr);
extern int t_isalnum(const char *ptr);

My current assessment is that these are best addressed after patch [0],
because we need locale-provider-aware character classification functions.

[0]:
https://www.postgresql.org/message-id/flat/2830211e1b6e6a2e26d845780b03e125281ea17b(dot)camel(at)j-davis(dot)com

On 02.12.24 11:57, Peter Eisentraut wrote:
> Infamously, the tsearch locale support in src/backend/tsearch/
> ts_locale.c still depends on libc environment variable locale settings
> and is not caught up with pg_locale_t, collations, ICU, and all that
> newer stuff.  This is used in the tsearch facilities themselves, but
> also in other modules such as ltree, pg_trgm, and unaccent.
>
> Several of the functions are wrappers around <ctype.h> functions, like
>
> int
> t_isalpha(const char *ptr)
> {
>     int         clen = pg_mblen(ptr);
>     wchar_t     character[WC_BUF_LEN];
>     pg_locale_t mylocale = 0;   /* TODO */
>
>     if (clen == 1 || database_ctype_is_c)
>         return isalpha(TOUCHAR(ptr));
>
>     char2wchar(character, WC_BUF_LEN, ptr, clen, mylocale);
>
>     return iswalpha((wint_t) character[0]);
> }
>
> So this has multibyte and encoding awareness, but does not observe
> locale provider or collation settings.
>
> As an easy start toward fixing this, I think several of these functions
> we don't even need.
>
> t_isdigit() and t_isspace() are just used to parse various configuration
> and data files, and surely we don't need support for encoding-dependent
> multibyte support for parsing ASCII digits and ASCII spaces.  At least,
> I didn't find any indications in the documentation of these file formats
> that they are supposed to support that kind of thing.  So these can be
> replaced by the normal isdigit() and isspace().
>
> There is one call to t_isprint(), which is similarly used only to parse
> some flags in a configuration file.  From the surrounding code you can
> deduce that it's only called on single-byte characters, so it can
> similarly be replaced by plain issprint().
>
> Note, pg_trgm has some compile-time options with macros such as
> KEEPONLYALNUM and IGNORECASE.  AFAICT, these are not documented, and the
> non-default variant is not supported by any test cases.  So as part of
> this undertaking, I'm going to remove the non-default variants if they
> are in the way of cleanup.