On Fri, 2025-06-13 at 18:41 +0200, Daniel Verite wrote:
> > The main challenge is backwards compatibility.
> Why would it be that bad?
> FTS indexes don't get corrupted that way. You may get different
> lexems before and after the upgrade for some documents, and then
> what?
It would produce diffe
Jeff Davis wrote:
> The main challenge is backwards compatibility. Users of FTS would need
> to recreate all of their tsvectors and indexes dependent on them. It's
> even possible that some users only have tsvectors and don't store the
> original data in the database, which would further c
On Tue, 2025-06-10 at 23:44 +0200, Daniel Verite wrote:
> I may miss something, but I don't see a
> technical reason why this code could not be taught to call the
> equivalent
> functions of the current collation provider, following the same
> principles
> as the regex code.
The main challenge is
Jeff Davis wrote:
> Even if it's not a collatable type, it should use the database
> collation rather than going straight to libc. Again, is that something
> that can ever be fixed or are we just stuck with libc semantics for
> full text search permanently, even if you initialize the clust
On Fri, 2025-06-06 at 15:47 -0700, Jeff Davis wrote:
> > > * Force the environment variables LC_COLLATE=C and LC_CTYPE=C
> > > unconditionally, and pg_perm_setlocale() them
> >
> > Currently that would be a regression for some people, because
> > when LC_CTYPE=C, the FTS parser produces substandar
On Fri, 2025-06-06 at 22:03 +0200, Daniel Verite wrote:
> +1 for the patch
Thank you, committed.
>
> Here we let 'locale' or 'lc_collate/lc_ctype' which is the same
> thing,
> defaulting from the template database.
Right, in the normal case it's OK, but if anything goes wrong, it gets
fairly co
Jeff Davis wrote:
> I have attached a patch 0001 that
> fixes a misleading hint, but it's still not great.
+1 for the patch
> When using ICU or the builtin provider, it still requires coming up
> with some valid locale name for LC_COLLATE and LC_CTYPE
No, since the following invocation