Re: Should we add xid_current() or a int8->xid cast?

On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)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.