On 19.10.25 02:29, Jeff Davis wrote:
On Fri, 2025-10-17 at 18:15 +0200, Peter Eisentraut wrote:
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.
I
On Fri, 2025-10-17 at 18:15 +0200, Peter Eisentraut wrote:
>
> 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.
I believe the new code does c
tsvector and tsquery are not collatable types, but they do need locale
information to parse the original text. It would not do any good to
make it a collatable type, because a COLLATE clause would typically be
applied after the parsing is done.
Previously, tsearch used the database CTYPE for parsi
On Tue, 2025-10-07 at 15:49 -0700, Jeff Davis wrote:
> This patch series allows tsearch to use the database default locale
> for
> parsing. If the database collation is libc, there's no change.
I committed a couple of the refactoring patches and rebased. v3
attached.
v3-0003 which eliminates the
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
parsin