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: http://www.postgresql.org/mailpref/pgsql-hackers
