Re: Windows default locale vs initdb

Поиск
Список
Период
Сортировка
От Juan José Santamaría Flecha
Тема Re: Windows default locale vs initdb
Дата
Msg-id CAC+AXB0RAovp=Ekv3CxxDTN+8tpbnyXQ8x2nNZPq2Ye9RZnQRA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Windows default locale vs initdb  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers

On Tue, Jul 19, 2022 at 12:59 AM Thomas Munro <thomas.munro@gmail.com> wrote:
Now that museum-grade Windows has been defenestrated, we are free to
call GetUserDefaultLocaleName().  Here's a patch.

This LGTM. 

I think we should also convert to POSIX format when making the
collname in your pg_import_system_collations() proposal, so that
COLLATE "en_US" works (= a SQL identifier), but that's another
thread[1].  I don't think we should do it in collcollate or
datcollate, which is a string for the OS to interpret.

That thread has been split [1], but that is how the current version behaves.

With my garbage collector hat on, I would like to rip out all of the
support for traditional locale names, eventually.  Deleting kludgy
code is easy and fun -- 0002 is a first swing at that -- but there
remains an important unanswered question.  How should someone
pg_upgrade a "English_Canada.1521" cluster if we now reject that name?
 We'd need to do a conversion to "en-CA", or somehow tell the user to.
Hmmmm.
 
Is there a safe way to do that in pg_upgrade or would we be forcing users to pg_dump into the new cluster?
 

Regards,

Juan José Santamaría Flecha

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

Предыдущее
От: Japin Li
Дата:
Сообщение: Re: Memory leak fix in psql
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: i.e. and e.g.