Re: [17] collation provider "builtin" - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [17] collation provider "builtin"
Date
Msg-id 98ff792bbb89993394becb4bf5e8115d6f9dc817.camel@j-davis.com
Whole thread Raw
In response to Re: [17] collation provider "builtin"  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Fri, 2023-06-16 at 16:01 +0200, Peter Eisentraut wrote:
> What happens if after this patch you continue to specify
> provider=libc
> and locale=C?  Do you then get the "slow" path?

Users can continue to use the libc provider as they did before and the
fast path will still work.

> Should there be some logic in pg_dump to change the provider if
> locale=C?

That's not a part of this proposal.

> What is the transition plan?

The built-in provider is for users who want to choose a provider that
is guaranteed not to have the problems of an external provider
(versioning, tracking affected objects, corrupt indexes, and slow
performance). If they initialize with --locale-provider=builtin and --
locale=C, and they want to choose a different locale for another
database, they'll need to specifically choose libc or ICU. Of course
they can still use specific collations attached to columns or queries
as required.

It also acts as a nice complement to ICU (which doesn't support the C
locale) or a potential replacement for many uses of the libc provider
with the C locale. We can discuss later exactly how that will look, but
even if the builtin provider needs to be explicitly requested (as in
the current patch), it's still useful, so I don't think we need to
decide now.

We should also keep in mind that whatever provider is selected at
initdb time also becomes the default for future databases.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: David Zhang
Date:
Subject: Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH
Next
From: Mikhail Gribkov
Date:
Subject: Fixing tab-complete for dollar-names