On Fri, Aug 2, 2019 at 10:42 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Thu, Jul 25, 2019 at 1:11 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Thu, Jul 25, 2019 at 12:42 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Andres Freund <and...@anarazel.de> writes: > > > > On 2019-07-24 20:34:39 -0400, Tom Lane wrote: > > > >> Yeah, I would absolutely NOT recommend that you open that can of worms > > > >> right now. We have looked at adding unsigned integer types in the past > > > >> and it looked like a mess. > > > > > > > I assume Thomas was thinking more of another bespoke type like xid, just > > > > wider. There's some notational advantage in not being able to > > > > immediately do math etc on xids. > > > > > > Well, we could invent an xid8 type if we want, just don't try to make > > > it part of the numeric hierarchy (as indeed xid isn't). > > > > Yeah, I meant an xid64/xid8/fxid/pg_something/... type that isn't a > > kind of number.
I thought about how to deal with the transition to xid8 for the txid_XXX() family of functions. The best idea I've come up with so far is to create a parallel xid8_XXX() family of functions, and declare the bigint-based functions to be deprecated, and threaten to drop them from a future release. The C code for the two families can be the same (it's a bit of a dirty trick, but only until the txid_XXX() variants go away). Here's a PoC patch demonstrating that. Not tested much, yet, probably needs some more work, but I wanted to see if others thought the idea was terrible first. I wonder if there is a better way to share hash functions than the hack in check_hash_func_signature(), which I had to extend to cover xid8. Adding to CF. -- Thomas Munro https://enterprisedb.com
0001-Add-SQL-type-xid8-to-expose-FullTransactionId-to-use.patch
Description: Binary data
0002-Introduce-xid8-variants-of-the-txid_XXX-fmgr-functio.patch
Description: Binary data
