[PATCH] Add regression test for mismatched ENCODING and LOCALE in CREATE DATABASE
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t139730psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 12:27 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t139730_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t139730_1 && git checkout t139730_1Patchset v1 (message #1) is on t139730_1
Hi,
While reading the CREATE DATABASE documentation at
https://www.postgresql.org/docs/current/sql-createdatabase.html, I
noticed the following sentence:
"The specified locale and encoding settings must match, or an error
will be reported."
However, we do not currently have regression coverage for that failure case.
This patch adds a regression test covering incompatible ENCODING and
LOCALE combinations, for example:
CREATE DATABASE dbtest
LOCALE 'en_US.UTF-8'
ENCODING LATIN1
TEMPLATE template0;
Which is expected to fail due to the encoding/locale mismatch.
The patch only adds test coverage and does not change backend behavior.
Regards,
Yushu
Yushu Chen <gentcys@gmail.com> writes:
While reading the CREATE DATABASE documentation at
https://www.postgresql.org/docs/current/sql-createdatabase.html, I
noticed the following sentence:
"The specified locale and encoding settings must match, or an error
will be reported."
However, we do not currently have regression coverage for that failure case.
The reason there is no test for that is that the spelling of locale
names, and indeed the presence of any particular locale, is variable
across platforms. Your proposed test case might work fine on your
machine, but it will fail on a nontrivial fraction of our buildfarm
(where "fail" means "produce some other error message than what the
test is expecting").
As a recent example where I too was overoptimistic about this,
see the sad history of my attempts to install coverage of NLS
translation (8c498479d, 5b275a6e1, fe7ede45f, 7db6809ce,
84a3778c7, 462e24765).
We could perhaps install the test with multiple variant files to
accept the cases we see in practice. But that would be a pain
in the rear for maintenance, and you have to wonder what it'd
actually be proving.
regards, tom lane