Simplify pg_collation.collversion for Windows libc
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:t47949psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:31 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 t47949_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 t47949_1 && git checkout t47949_1Patchset v1 (message #1) is on t47949_1
Hi,
Currently the libc collation version for Windows has two components
coming from the NLSVERSIONINFOEX structure [1]https://learn.microsoft.com/en-us/windows/win32/api/winnls/ns-winnls-nlsversioninfoex
dwNLSVersion and dwDefinedVersion
So we get version numbers looking like this (with 16 beta1):
postgres=# select collversion,count(*) from pg_collation group by
collversion;
collversion | count
---------------+-------
| 5
1539.5,1539.5 | 1457
(2 rows)
According to [1]https://learn.microsoft.com/en-us/windows/win32/api/winnls/ns-winnls-nlsversioninfoex the second number is obsolete, and AFAICS we should
expose only the first.
<quote>
dwDefinedVersion
Defined version. This value is used to track changes in the repertoire
of Unicode code points. The value increments when the Unicode
repertoire is extended, for example, if more characters are defined.
Starting with Windows 8: Deprecated. Use dwNLSVersion instead.
</quote>
PFA a patch implementing that suggestion.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/winnls/ns-winnls-nlsversioninfoex
https://learn.microsoft.com/en-us/windows/win32/api/winnls/ns-winnls-nlsversioninfoex
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite
On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite <daniel@manitou-mail.org> wrote:
postgres=# select collversion,count(*) from pg_collation group by
collversion;
collversion | count
---------------+-------
| 5
1539.5,1539.5 | 1457
(2 rows)According to [1] the second number is obsolete, and AFAICS we should
expose only the first.
Would it be a good idea to remove or ignore the trailing /,*$/
somewhere, perhaps during pg_upgrade, to avoid bogus version mismatch
warnings?
On 06.06.23 03:21, Thomas Munro wrote:
On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite <daniel@manitou-mail.org> wrote:
postgres=# select collversion,count(*) from pg_collation group by
collversion;
collversion | count
---------------+-------
| 5
1539.5,1539.5 | 1457
(2 rows)According to [1] the second number is obsolete, and AFAICS we should
expose only the first.Would it be a good idea to remove or ignore the trailing /,*$/
somewhere, perhaps during pg_upgrade, to avoid bogus version mismatch
warnings?
I wonder whether it's worth dealing with this, versus just leaving it
all alone.