Hi, On 2019-07-25 12:20:58 +1200, Thomas Munro wrote: > 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.
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
