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

On Fri, Aug 2, 2019 at 10:42 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Thu, Jul 25, 2019 at 1:11 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > On Thu, Jul 25, 2019 at 12:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > Andres Freund <andres@anarazel.de> writes:
> > > > On 2019-07-24 20:34:39 -0400, Tom Lane wrote:
> > > >> Yeah, I would absolutely NOT recommend that you open that can of worms
> > > >> right now.  We have looked at adding unsigned integer types in the past
> > > >> and it looked like a mess.
> > >
> > > > I assume Thomas was thinking more of another bespoke type like xid, just
> > > > wider.  There's some notational advantage in not being able to
> > > > immediately do math etc on xids.
> > >
> > > Well, we could invent an xid8 type if we want, just don't try to make
> > > it part of the numeric hierarchy (as indeed xid isn't).
> >
> > Yeah, I meant an xid64/xid8/fxid/pg_something/... type that isn't a
> > kind of number.

I thought about how to deal with the transition to xid8 for the
txid_XXX() family of functions.  The best idea I've come up with so
far is to create a parallel xid8_XXX() family of functions, and
declare the bigint-based functions to be deprecated, and threaten to
drop them from a future release.  The C code for the two families can
be the same (it's a bit of a dirty trick, but only until the
txid_XXX() variants go away).  Here's a PoC patch demonstrating that.
Not tested much, yet, probably needs some more work, but I wanted to
see if others thought the idea was terrible first.

I wonder if there is a better way to share hash functions than the
hack in check_hash_func_signature(), which I had to extend to cover
xid8.

Adding to CF.

-- 
Thomas Munro
https://enterprisedb.com