Re: PRI?64 vs Visual Studio (2022)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2025-11-19T02:28:35Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Test PRI* macros even when we can't test NLS translation.
- 462e2476525e 19 (unreleased) landed
-
Avoid requiring Spanish locale to test NLS infrastructure.
- 7db6809ced44 19 (unreleased) landed
-
Drop support for MSVCRT's float formatting quirk.
- 6b46669883fa 19 (unreleased) landed
-
Drop support for MSVCRT's %I64 format strings.
- 7ab9b34614c2 19 (unreleased) landed
-
Use PRI?64 instead of "ll?" in format strings (continued).
- a0ed19e0a9ef 18.0 cited
-
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 cited
-
Make float exponent output on Windows look the same as elsewhere.
- f1885386f624 12.0 cited
Thomas Munro <thomas.munro@gmail.com> writes: > We don't even test -Dnls on the Windows CI task, so the fact that it > passes there doesn't mean much (if our tests would even pick up > <PRI*64> expansion failure, not sure). We should probably do > something about that and/or its absence from the build farm. We're > effectively counting on the EDB packaging team or end users to tell us > if we break localisation on this platform. I'm pretty certain that we do not test NLS localization at all, anywhere :-(. (There are no test cases checking enable_nls, which would be a necessary thing to not fail on buildfarm critters not using NLS.) I agree that starting to rely on PRI?64 in translatable strings is raising the bar a good deal, so maybe it's time to do something about that. regards, tom lane