On 8/18/16 5:46 AM, Amit Kapila wrote:
I think there is a value in exposing such a variant which takes bigint
and internally converts it to xid.  I am not sure the semantics for

I think that's a bad idea because you have the exact same problems we have now: bigint is signed, epoch is not.

the other proposal txid_recent() is equivalent to what we have for
txid_current().  One thing which is different is that txid_current()
allocates a new transaction if there is currently none.  If you

Right, and it would be nice to be able to tell if an XID has been assigned to your transaction or not; something you currently can't do.

plainly want to convert it to 32 bit xid, then may be txid_convert or
something like that is more suitable.

I think we need to either add real types for handling XID/epoch/TXID or finally create uint types. It's *way* too easy to screw things up the way they are today.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to