Обсуждение: Use pg_current_xact_id() instead of deprecated txid_current()

Hi hackers,

Commit 4c04be9b05a [0] 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.

[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4c04be9b05ad2ec5acd27c3417bf075c13cab134

-- 
Best regards,
Shinya Kato
NTT OSS Center

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], xid8 was
intentionally designed not to support arithmetic.

[0] https://www.postgresql.org/message-id/CA%2BhUKGL0TKUm3g8dywe6zVeSJLkaRYet1CgXMsB%2BF3bXJRJHFA%40mail.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