| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Ertan Küçükoglu <ertan(dot)kucukoglu(at)gmail(dot)com> |
| Subject: | Re: Windows default locale vs initdb |
| Date: | 2024-07-22 02:51:49 |
| Message-ID: | CA+hUKGL5mBN3JQuebAPbX0yxDNtpui04J+KSy2F7KBbhLGaJig@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ertan Küçükoglu offered to try to review and test this, so here's a rebase.
Some notes:
* it turned out that the Turkish i/I test problem I mentioned earlier
in this thread[1] was just always broken on Windows, we just didn't
ever test with UTF-8 before Meson took over; it's skipped now, see
commit cff4e5a3[2]
* it seems that you can't actually put encodings like .1252 on the end
(.UTF-8 must be a special case); I don't know if we should look into a
better UTF-8 mode for modern Windows, but that'd be a separate project
* this patch only benefits people who run initdb.exe without
explicitly specifying a locale; probably a good number of real systems
in the wild actually use EDB's graphical installer which initialises a
cluster and has its own way of choosing the locale, as discussed in
Ertan's thread[3]
[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJZskvCh%3DQm75UkHrY6c1QZUuC92Po9rponj1BbLmcMEA%40mail.gmail.com#3a00c08214a4285d2f3c4297b0ac2be2
[2] https://github.com/postgres/postgres/commit/cff4e5a3
[3] https://www.postgresql.org/message-id/flat/CAH2i4ydECHZPxEBB7gtRG3vROv7a0d3tqAFXzcJWQ9hRsc1znQ%40mail.gmail.com
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-MinGW-has-GetLocaleInfoEx.patch | text/x-patch | 1.4 KB |
| v5-0002-Default-to-IETF-BCP-47-locale-names-in-initdb-on-.patch | text/x-patch | 4.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2024-07-22 02:56:49 | RE: Slow catchup of 2PC (twophase) transactions on replica in LR |
| Previous Message | Richard Guo | 2024-07-22 02:43:50 | Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop() |