Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nUrJe-0003HI-Rx for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Mar 2022 14:41:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nUrJd-0007tZ-My for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Mar 2022 14:41:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nUrJd-0007tQ-DW for pgsql-hackers@lists.postgresql.org; Thu, 17 Mar 2022 14:41:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nUrJW-0001yU-Pu for pgsql-hackers@lists.postgresql.org; Thu, 17 Mar 2022 14:41:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 22HEf8wx771049; Thu, 17 Mar 2022 10:41:08 -0400 From: Tom Lane To: Japin Li cc: Alexander Korotkov , Peter Eisentraut , Aleksander Alekseev , Kyotaro Horiguchi , Maxim Orlov , Pavel Borisov , Ilya Anfimov , pgsql-hackers@lists.postgresql.org Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) In-reply-to: References: <85f2c6c5-f8a6-5da8-67a6-9e48f56c7f77@enterprisedb.com> Comments: In-reply-to Japin Li message dated "Thu, 17 Mar 2022 22:07:32 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <771047.1647528068.1@sss.pgh.pa.us> Date: Thu, 17 Mar 2022 10:41:08 -0400 Message-ID: <771048.1647528068@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Japin Li writes: > Maybe, we should format it to string before for localization messages, > like the following code snippet comes from pg_backup_tar.c. > However, I do not think it is a good way. > snprintf(buf1, sizeof(buf1), INT64_FORMAT, (int64) len); > snprintf(buf2, sizeof(buf2), INT64_FORMAT, (int64) th->fileLen); > fatal("actual file length (%s) does not match expected (%s)", > buf1, buf2); That used to be our standard practice before we switched to always relying on our own snprintf.c. Now, we know that "%lld" with an explicit cast to long long will work, so that's the preferred method for printing 64-bit values in localizable strings. Not all of the old code has been updated, though. regards, tom lane