On Thu, Jul 25, 2019 at 12:06 PM Andres Freund <and...@anarazel.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
