Thread
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't copy datlocale from template unless provider matches.
- 295a39770e6f 19 (unreleased) landed
- 06697909b669 18.0 landed
-
CREATE DATABASE copies datlocale even if datlocprovider differs
Jeff Davis <pgsql@j-davis.com> — 2025-07-29T23:33:45Z
initdb -D data --locale-provider=builtin --builtin-locale='C.UTF-8' CREATE DATABASE d2 TEMPLATE template0 LOCALE_PROVIDER 'icu'; WARNING: ICU locale "C.UTF-8" has unknown language "c" HINT: To disable ICU locale validation, set the parameter "icu_validation_level" to "disabled". CREATE DATABASE SELECT datlocale FROM pg_database WHERE datname='d2'; datlocale ----------- C.UTF-8 (1 row) It's only an issue if template0 is builtin and the new database is icu. libc doesn't use the datlocale field, and the builtin provider will reject ICU locale names. ICU is less strict for historical reasons. I think that should throw an error rather than trying to reinterpret datlocale for the new provider. Patch attached, intended to backport through 17. In theory that could break existing CREATE DATABASE commands, but given that it's such a narrow case I don't think it's a major problem. We could mitigate it by patching only 18+. Thoughts? Regards, Jeff Davis
-
Re: CREATE DATABASE copies datlocale even if datlocprovider differs
Jeff Davis <pgsql@j-davis.com> — 2025-08-05T16:28:24Z
On Tue, 2025-07-29 at 16:33 -0700, Jeff Davis wrote: > We > could mitigate it by patching only 18+. Thoughts? I decided to backport only through 18. If someone runs into this in version 17, the worst that can happen is that they have a poorly- validated locale for ICU, which was a possibility anyway. Regards, Jeff Davis