Horton

Re: PRI?64 vs Visual Studio (2022)

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

View thread
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-20T01:23:01Z
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 →

  1. Test PRI* macros even when we can't test NLS translation.

  2. Avoid requiring Spanish locale to test NLS infrastructure.

  3. Drop support for MSVCRT's float formatting quirk.

  4. Drop support for MSVCRT's %I64 format strings.

  5. Use PRI?64 instead of "ll?" in format strings (continued).

  6. Use <stdint.h> and <inttypes.h> for c.h integers.

  7. Make float exponent output on Windows look the same as elsewhere.

Attachments

I wrote:
> 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.

Oh, better idea about that: let's make regress.so have its own
translation domain.  This allows testing the TEXTDOMAIN mechanism
as well as the basics, and it keeps the patch pretty self-contained.

I was amused to see that "make update-po" was able to fill in
translations for all of the pre-existing ereport's in regress.c.
I guess they all had duplicates somewhere else?  But I take no
credit or blame for any of those translations.

The other loose ends remain.

			regards, tom lane