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

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. 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.

--
Thomas Munro
https://enterprisedb.com