Use pg_current_xact_id() instead of deprecated txid_current()
Hi hackers,
Commit 4c04be9b05a [0]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4c04be9b05ad2ec5acd27c3417bf075c13cab134 introduced xid8-based functions to replace the
txid_XXX family. However, several test files were still using
txid_current() instead of the newer pg_current_xact_id(). Attached
patch replaces all remaining call sites in tests.
Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.
--
Best regards,
Shinya Kato
NTT OSS Center
Attachments:
v1-0001-Use-pg_current_xact_id-instead-of-deprecated-txid.patchapplication/octet-stream; name=v1-0001-Use-pg_current_xact_id-instead-of-deprecated-txid.patchDownload+25-26
On 2026-02-08, Shinya Kato wrote:
Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.
I think it may be better to add some operators, or was there a rationale for these not being there?
--
Álvaro Herrera
On Sun, Feb 8, 2026 at 7:50 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
On 2026-02-08, Shinya Kato wrote:
Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.I think it may be better to add some operators, or was there a rationale for these not being there?
Thank you for your comment!
I don't have a strong opinion on this, but according to [0]/messages/by-id/CA+hUKGL0TKUm3g8dywe6zVeSJLkaRYet1CgXMsB+F3bXJRJHFA@mail.gmail.com, xid8 was
intentionally designed not to support arithmetic.
[0]: /messages/by-id/CA+hUKGL0TKUm3g8dywe6zVeSJLkaRYet1CgXMsB+F3bXJRJHFA@mail.gmail.com
--
Best regards,
Shinya Kato
NTT OSS Center
=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes:
On 2026-02-08, Shinya Kato wrote:
Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.
I think it may be better to add some operators, or was there a rationale for these not being there?
I'm fairly concerned about overloading the arithmetic operators with
unsigned versions. The reason we never invented SQL-level uint8 and
such is fear of getting a lot of "ambiguous operator" errors. Now,
if we are careful not to create implicit casts between xid[8] and
any ordinary type, maybe it'd be okay to invent xid+int, xid8-int,
and a few more.
As things stand, I don't find the proposed patch to be an improvement.
regards, tom lane
On Mon, Feb 9, 2026 at 1:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes:
On 2026-02-08, Shinya Kato wrote:
Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.I think it may be better to add some operators, or was there a rationale for these not being there?
I'm fairly concerned about overloading the arithmetic operators with
unsigned versions. The reason we never invented SQL-level uint8 and
such is fear of getting a lot of "ambiguous operator" errors. Now,
if we are careful not to create implicit casts between xid[8] and
any ordinary type, maybe it'd be okay to invent xid+int, xid8-int,
and a few more.
Got it. I’ll give it a try, thanks.
As things stand, I don't find the proposed patch to be an improvement.
I agree that casting xid8 to bigint was not the right approach.
However, I still believe it's important to move away from using
deprecated functions.
--
Best regards,
Shinya Kato
NTT OSS Center
On Mon, Feb 9, 2026 at 9:07 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
On Mon, Feb 9, 2026 at 1:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes:
On 2026-02-08, Shinya Kato wrote:
Since pg_current_xact_id() returns xid8 which does not support
arithmetic operators, places that need "xid + 1" cast the result via
::text::bigint first.I think it may be better to add some operators, or was there a rationale for these not being there?
I'm fairly concerned about overloading the arithmetic operators with
unsigned versions. The reason we never invented SQL-level uint8 and
such is fear of getting a lot of "ambiguous operator" errors. Now,
if we are careful not to create implicit casts between xid[8] and
any ordinary type, maybe it'd be okay to invent xid+int, xid8-int,
and a few more.Got it. I’ll give it a try, thanks.
I have added the + and - operators for the xid8 type in the v2-0001
patch. This allows for direct arithmetic and eliminates the need for
casting through text and bigint. Specifically, I implemented:
xid8 + int8 -> xid8
int8 + xid8 -> xid8
xid8 - int8 -> xid8
xid8 - xid8 -> int8
Additionally, the v2-0002 patch removes the existing ::text::bigint
casts where they are no longer necessary.
--
Best regards,
Shinya Kato
NTT OSS Center