Re: make tsearch use the database default locale
| От | Peter Eisentraut |
|---|---|
| Тема | Re: make tsearch use the database default locale |
| Дата | |
| Msg-id | e0a4b081-550f-45b6-93d1-405a49958884@eisentraut.org обсуждение исходный текст |
| Ответ на | make tsearch use the database default locale (Jeff Davis <pgsql@j-davis.com>) |
| Ответы |
Re: make tsearch use the database default locale
|
| Список | 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).)
В списке pgsql-hackers по дате отправления: