From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: make tsearch use the database default locale |
Date: | 2025-10-17 16:15:47 |
Message-ID: | e0a4b081-550f-45b6-93d1-405a49958884@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
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).)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-10-17 16:18:40 | Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master |
Previous Message | Peter Eisentraut | 2025-10-17 15:23:22 | Re: Change initdb default to the builtin collation provider |