Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
От | Japin Li |
---|---|
Тема | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
Дата | |
Msg-id | MEYP282MB1669404C314BAD7EA603143FB6129@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
Список | pgsql-hackers |
On Thu, 17 Mar 2022 at 21:31, Alexander Korotkov <aekorotkov@gmail.com> wrote: > On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut > <peter.eisentraut@enterprisedb.com> wrote: >> On 17.03.22 14:12, Aleksander Alekseev wrote: >> > v19-0001 changes the format string for XIDs from %u to XID_FMT. This >> > refactoring allows us to switch to UINT64_FORMAT by changing one >> > #define in the future patches. >> > >> > Kyotaro suggested using `errmsg("blah blah %lld ..", (long long) >> > xid)` instead in order to simplify localization of the error messages. >> > Personally I don't have a strong opinion here. Either approach will >> > work and will affect the error messages eventually. Please let us know >> > what you think. >> >> This is not a question of simplification. Translatable messages with >> embedded macros won't work. This patch isn't going to be acceptable. > > I've suspected this, but wasn't sure. Thank you for clarification. > 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); -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
В списке pgsql-hackers по дате отправления: