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: Álvaro Herrera <alvherre@kurilemu.de>, Peter Eisentraut <peter@eisentraut.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-11-19T22:23:53Z
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
Attachments
- v1-0001-Simple-test-of-NLS-translation.patch (text/x-diff) patch v1-0001
I wrote: > I agree with the idea of just using a single test message that checks > all the PRI* macros we care about. I don't think we need to invent a > whole new translation for this. I'd be inclined to just get the > desired translated string pushed into one or two .po files in HEAD, > then we can start testing with those specific languages, and we're > good. Over time the translators would presumably get translations > into other .po files, and then maybe we'd want to expand the set of > tested languages, or maybe that wouldn't really buy much. (Managing > the encoding of the expected-file might be tricky if you got too > ambitious about that.) Just as proof-of-concept, this is approximately what I think we should do to begin with. The main thing that's likely wrong here is that I just manually shoved a new entry into src/backend/po/es.po. I suspect that the .po-extraction machinery would fail to pick up that string because it's in src/test/regress/regress.c. We could hack it to do that, or we could put the test function into some backend file. I don't have much sense of which would be cleaner. Lesser loose ends: I didn't bother fleshing out the test message to cover all of the likely PRI* cases, and my Spanish probably sucks. I'm also unsure if this will work as-is on Windows; are the LC_MESSAGES settings the same there? regards, tom lane