On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger > <mark.dil...@enterprisedb.com> wrote: > > The "xid8_" warts are partly motivated by having a type named "xid8", which > > is a bit of a wart in itself. > > Just a thought for the future, not sure if it's a good one: would it > seem less warty in years to come if we introduced xid4 as an alias for > xid, and preferred the name xid4? Then it wouldn't look so much like > xid is the "real" transaction ID type and xid8 is some kind of freaky > extended version; instead it would look like xid4 and xid8 are narrow > and wide transaction IDs, and xid is just a historical name for xid4.
I'll look into proposing that for PG14. One reason I like that idea is that system view names like backend_xid could potentially retain their names while switching to xid8 type, (maybe?) breaking fewer queries and avoiding ugly names, on the theory that _xid doesn't specify whether it's xid4 or an xid8. > > > pg_current_xact_id() > > > pg_current_xact_id_if_assigned() > > > pg_xact_status(xid8) > > > pg_current_snapshot() > > > pg_snapshot_xmin(pg_snapshot) > > > pg_snapshot_xmax(pg_snapshot) > > > pg_snapshot_xip(pg_snapshot) > > > pg_visible_in_snapshot(xid8, pg_snapshot) > > As such, I'm ±0 for the change. > > I'll let this sit for another day and see if some more reactions appear. Hearing no objections, pushed. Happy to reconsider these names before release if someone finds a problem with this scheme.
