Re: [17] collation provider "builtin"

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: [17] collation provider "builtin"
Дата
Msg-id 98ff792bbb89993394becb4bf5e8115d6f9dc817.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: [17] collation provider "builtin"  (Peter Eisentraut <peter@eisentraut.org>)
Список 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 по дате отправления:

Предыдущее
От: David Zhang
Дата:
Сообщение: Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH
Следующее
От: Mikhail Gribkov
Дата:
Сообщение: Fixing tab-complete for dollar-names