Re: Should we add xid_current() or a int8->xid cast?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Thomas Munro <thomas.munro@gmail.com>,
Fujii Masao <masao.fujii@oss.nttdata.com>,
Mark Dilger <hornschnorter@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-04-02T19:20:30Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2020-04-02 14:33:18 -0300, Alvaro Herrera wrote: >> Hmm, for some reason I had it in my head that we would make these use an >> "epoch/val" output format rather than raw uint64 values. > Why would we do that? IMO the goal should be to reduce awareness of the > 32bitness of normal xids from as many places as possible, and treat them > as an internal space optimization. If they're just int64s then you don't need special functions to do things like finding the min or max in a column of them. regards, tom lane
Commits
-
Introduce xid8-based functions to replace txid_XXX.
- 4c04be9b05ad 13.0 landed
-
Add SQL type xid8 to expose FullTransactionId to users.
- aeec457de8a8 13.0 landed
-
Replace the former method of determining snapshot xmax --- to wit, calling
- 6bd4f401b0cb 8.3.0 cited