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