On Sun, Mar 30, 2025 at 6:24 AM Peter Eisentraut wrote:
> I have committed v2-0001, omitting the parts that I had flagged in my
> review. I have also committed v2-0002. From my perspective, this can
> conclude this thread.
Thank you! Fingers crossed that the translation updates go as
smoothly
On 10.03.25 10:49, Peter Eisentraut wrote:
On 02.03.25 22:08, Thomas Munro wrote:
On Mon, Mar 3, 2025 at 6:21 AM Peter Eisentraut
wrote:
On 05.12.24 23:18, Thomas Munro wrote:
Old: errmsg("hello %llu", (unsigned long long) x)
New: errmsg("hello %" PRIu64, x)
I have committed the
On 02.03.25 22:08, Thomas Munro wrote:
And one more thing like that: in a couple of places we see warnings on
macOS CI that I'd missed: when printing the result of i64abs() as
PRId64, because it happens to use labs() and it happens to define
int64_t as long long, [...]. I
suppose we should cast
Thomas Munro writes:
> On Mon, Mar 17, 2025 at 8:09 PM Tom Lane wrote:
>> Hmm, I find that comment fairly scary. How do we know that the
>> runtime library actually gets this right on every supported platform?
> I don't know too much about libintl and its history other than what
> I've looked u
On Mon, Mar 17, 2025 at 11:52 PM Thomas Munro wrote:
> tmunro@s11-sparc:~/gettext-hacking$ gcc test.c
> tmunro@s11-sparc:~/gettext-hacking$ ./a.out
> la réponse est 42
And just to be paranoid, I checked a few more things: the .mo
definitely contains the literal "PRId64" (rearranged as
"^@PRId64^
On Mon, Mar 17, 2025 at 8:03 PM Peter Eisentraut wrote:
> On 15.03.25 03:42, Thomas Munro wrote:
> > So we should make pgoff_t a typedef for int64_t everywhere. It's a
> > bit annoying that we have to teach everyone to remember to use PRId64
> > to print it, though.
>
> The ramifications of such
On Mon, Mar 17, 2025 at 8:09 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > This is not really possible. The behavior is baked deeply into
> > the gettext code. (Also note that you don't only need support in
> > xgettext, which is part of our build system, but also in the runtime
> > librar
Peter Eisentraut writes:
> This is not really possible. The behavior is baked deeply into
> the gettext code. (Also note that you don't only need support in
> xgettext, which is part of our build system, but also in the runtime
> library, which we don't control.)
Hmm, I find that comment fa
On 15.03.25 03:42, Thomas Munro wrote:
- I don't think it's proper to assume that pgoff_t or off_t matches int64_t.
So we should make pgoff_t a typedef for int64_t everywhere. It's a
bit annoying that we have to teach everyone to remember to use PRId64
to print it, though.
The ramifications
On Mon, Mar 10, 2025 at 10:49 PM Peter Eisentraut wrote:
> On 02.03.25 22:08, Thomas Munro wrote:
> > Good plan, thanks. Here's a rebase.
>
> I think this went ok, and we can proceed here.
Cool, I'll post a new patch soon, but first a question about this bit:
> - I don't think it's proper to as
On 02.03.25 22:08, Thomas Munro wrote:
On Mon, Mar 3, 2025 at 6:21 AM Peter Eisentraut wrote:
On 05.12.24 23:18, Thomas Munro wrote:
Old: errmsg("hello %llu", (unsigned long long) x)
New: errmsg("hello %" PRIu64, x)
I have committed the subset of this patch for pg_checksums.c so
On 02.03.25 22:08, Thomas Munro wrote:
And one more thing like that: in a couple of places we see warnings on
macOS CI that I'd missed: when printing the result of i64abs() as
PRId64, because it happens to use labs() and it happens to define
int64_t as long long, and when printing a Datum as PRIx
Thomas Munro writes:
> I also added one more patch that I expect to be more contentious as it
> is a UX change. Why do we display LSNs with a slash?
While there's surely little reason to do that anymore, I think the
blast radius of such a change will be vastly greater than is warranted
by aesthe
On 05.12.24 23:18, Thomas Munro wrote:
Having learned some things about gettext based on clues[1] from Peter
E, I decided to see what it would take to expunge all (long long) and
similar casts now that we're using the standard types with system
support.
The short version is tha given uint64 x:
On 2024-Dec-06, Thomas Munro wrote:
> And no doubt .po file churn ...
> I don't know what tooling is used for that sort of stuff but I imagine
> that automated replacement might go a long way.
There's a msgfilter utility that can be used for automated updates. I
documented one usage a few years
On Fri, Dec 6, 2024 at 1:15 PM Melanie Plageman
wrote:
> So, will this fix the issue that when I do:
>
> uint64 somevar = 0;
> errmsg("hello %lu", somevar)
>
> locally on my x86-64 linux machine running ubuntu with whatever gcc-11
> comes out of the box, it compiles sans warnings, but in the
> min
On Thu, Dec 5, 2024 at 5:12 PM Thomas Munro wrote:
>
> Having learned some things about gettext based on clues[1] from Peter
> E, I decided to see what it would take to expunge all (long long) and
> similar casts now that we're using the standard types with system
> support.
>
> The short version
Hi,
Having learned some things about gettext based on clues[1] from Peter
E, I decided to see what it would take to expunge all (long long) and
similar casts now that we're using the standard types with system
support.
The short version is tha given uint64 x:
Old: errmsg("hello %llu", (unsig
18 matches
Mail list logo
