Re: Built-in CTYPE provider

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Built-in CTYPE provider
Дата
Msg-id 3117d30aa911b408b90420f4f280fa0c3b5851be.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Built-in CTYPE provider  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Built-in CTYPE provider  (Peter Eisentraut <peter@eisentraut.org>)
Re: Built-in CTYPE provider  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
On Wed, 2024-03-13 at 00:44 -0700, Jeff Davis wrote:
> New series attached. I plan to commit 0001 very soon.

Committed the basic builtin provider, supporting only the "C" locale.

There were a few changes since the last version I posted:

  * Added simplistic validation of the locale name to initdb.c (missing
before).
  * Consistently passed the locale name to
get_collation_actual_version(). In the previous patch, the caller
sometimes just passed NULL knowing that the builtin provider is not
versioned, but that's not the caller's responsibility.
  * pg_dump previously had some minor refactoring, which you had some
questions about. I eliminated that and just kept it to the changes
necessary for the builtin provider.
  * createdb --help was missing the --builtin-locale option
  * improved error checking order in createdb() to avoid a confusing
error message.

I also attached a rebased series.

0001 (the C.UTF-8 locale) is also close. Considering that most of the
infrastructure is already in place, that's not a large patch. You many
have some comments about the way I'm canonicalizing and validating in
initdb -- that could be cleaner, but it feels like I should refactor
the surrounding code separately first.

0002 (inlining utf8 functions) is also ready.

For 0003 and beyond, I'd like some validation that it's what you had in
mind.

Regards,
    Jeff Davis


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Support json_errdetail in FRONTEND builds
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Have pg_basebackup write "dbname" in "primary_conninfo"?