Hi,
On 2020-04-17 14:07:07 -0400, Robert Haas wrote:
> On Fri, Apr 17, 2020 at 1:45 PM Andres Freund <andres@anarazel.de> wrote:
> > You seem to be entirely disregarding my actual point, namely that
> > txid_current(), as well as some other txid_* functions, have returned
> > 64bit xids for many many years. txid_current() is the only function to
> > get the current xid in a reasonable way. I don't understand how a
> > proposal to add a 32/32 bit representation *in addition* to the existing
> > 32 and 64bit representations is going to improve the situation. Nor do I
> > see changing txid_current()'s return format as something we're going to
> > go for.
> >
> > I did not argue against a function to turn 64bit xids into epoch/32bit
> > xid or such.
>
> I thought we were talking about how the new xid8 type ought to behave.
Yes? But that type doesn't exist in isolation. Having yet another
significantly different representation of 64bit xids (as plain 64 bit
integers, and as some 32/32 epoch/xid split) would make an already
confusing situation even more complex.
Greetings,
Andres Freund