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

Hi,

On 2019-07-25 12:20:58 +1200, Thomas Munro wrote:
> On Thu, Jul 25, 2019 at 12:06 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > we have txid_current(), which returns an int8. But there's no convenient
> > way to convert that to type 'xid'. Which is fairly inconvenient, given
> > that we expose xids in various places.
> >
> > My current need for this was just a regression test to make sure that
> > system columns (xmin/xmax in particular) don't get broken again for ON
> > CONFLICT. But I've needed this before in other scenarios - e.g. age(xid)
> > can be useful to figure out how old a transaction is, but age() doesn't
> > work with txid_current()'s return value.
> >
> > Seems easiest to just add xid_current(), or add a cast from int8 to xid
> > (probably explicit?) that handles the wraparound logic correctly?
>
> Yeah, I was wondering about that. int8 isn't really the right type,
> since FullTransactionId is unsigned.

For now that doesn't seem that big an impediment...

> If we had a SQL type for 64 bit xids, it should be convertible to xid,
> and the reverse conversion should require a more complicated dance.
> Of course we can't casually change txid_current() without annoying
> people who are using it, so perhaps if we invent a new SQL type we
> should also make a new function that returns it.

Possibly we could add a fullxid or xid8, xid64, pg_xid64, ... type, and
have an implicit cast to int8?

Greetings,

Andres Freund