Horton

Re: make tsearch use the database default locale

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Date: 2025-10-17T16:15:47Z
Lists: pgsql-hackers 
On 08.10.25 00:49, Jeff Davis wrote:
> Previously, tsearch used the database CTYPE for parsing, but that's not
> good because it creates an unnecessary dependency on libc even when the
> user has requested another provider.
> 
> This patch series allows tsearch to use the database default locale for
> parsing. If the database collation is libc, there's no change.

This looks good to me overall.

> * Most of the patches are straightforward, but v1-0005 might need extra
> attention. There are quite a few cases there with subtle distinctions,
> and I might have missed something. For example, in the "C" locale,
> tsearch treats non-ascii characters as alpha, even though the libc
> functions do not do so (I preserved this behavior).

This is indeed a bit mysterious.  AFAICT, the behavior you describe is 
conditional on if (prs->usewide), so it apparently depends also on the 
encoding?  I'm not sure if the new code covers this.

After this patch set, char2wchar() can become a local function in 
pg_locale_libc.c.  (But we still need wchar2char() externally, so maybe 
it's not worth changing this (yes).)

Commits

  1. Make char2wchar() static.

  2. Remove obsolete global database_ctype_is_c.

  3. tsearch: use database default collation for parsing.

  4. Add pg_database_locale() to retrieve database default locale.

  5. Add pg_iswxdigit(), useful for tsearch.

  6. Add pg_iswalpha() and related functions.

  7. pg_regc_locale.c: rename some static functions.