Re: CREATE DATABASE command for non-libc providers

2025-06-13 Thread Jeff Davis
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

Re: CREATE DATABASE command for non-libc providers

2025-06-13 Thread Daniel Verite
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

Re: CREATE DATABASE command for non-libc providers

2025-06-11 Thread Jeff Davis
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

Re: CREATE DATABASE command for non-libc providers

2025-06-10 Thread Daniel Verite
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

Re: CREATE DATABASE command for non-libc providers

2025-06-09 Thread Jeff Davis
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

Re: CREATE DATABASE command for non-libc providers

2025-06-06 Thread Jeff Davis
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

Re: CREATE DATABASE command for non-libc providers

2025-06-06 Thread Daniel Verite
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