Re: PRI?64 vs Visual Studio (2022)

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Peter Eisentraut <peter@eisentraut.org>

Cc: Thomas Munro <thomas.munro@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-11-19T15:43:58Z

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

Peter Eisentraut <peter@eisentraut.org> writes:
> On 19.11.25 04:15, Tom Lane wrote:
>> I think we should do it
>> honestly with a regression test.  It doesn't need to be very
>> complicated --- I think checking one message in one translation is
>> sufficient, so long as it includes a PRI?64 usage.

> We could generate an English message catalog that translates all 
> messages unchanged, and run the whole test suite with that.  This would 
> exercise the whole gettext run-time machinery.

... except that if it were actually doing nothing whatsoever, you
could not tell.  This seems particularly troublesome for gettext,
since its fallback behavior is exactly to return the given string.
I'd prefer a test that fails in a visible way.

			regards, tom lane