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?
[1] https://www.postgresql.org/message-id/flat/0050ec23-34d9-2765-9015-98c04f0e18ac%40postgrespro.ru
Regards,
Juan José Santamaría Flecha
В списке pgsql-hackers по дате отправления: