From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Sravan Kumar <sravanvcybage(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_verifybackup: TAR format backup verification |
Date: | 2024-09-30 22:01:11 |
Message-ID: | 1636465.1727733671@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Sep 30, 2024 at 11:24 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Um, wait ... we do have strtou64(), so you should use that.
> The thing we should be worried about is not how large a JSON blob
> might be, but rather how large any file that appears in the data
> directory might be. So uint32 is out; and I think I hear you voting
> for uint64 over size_t.
Yes. size_t might only be 32 bits.
> But then how do you think we should print
> that? Cast to unsigned long long and use %llu?
Our two standard solutions are to do that or to use UINT64_FORMAT.
But UINT64_FORMAT is problematic in translatable strings because
then the .po files would become platform-specific, so long long
is what to use in that case. For a non-translated format string
you can do either.
> I don't understand what you think the widely-used, better solution is
> here.
What we just said above.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-09-30 22:04:14 | Re: ACL_MAINTAIN, Lack of comment content |
Previous Message | Andrei Lepikhov | 2024-09-30 21:52:11 | Re: apply_scanjoin_target_to_paths and partitionwise join |