Re: Should we add xid_current() or a int8->xid cast?
От | Robert Haas |
---|---|
Тема | Re: Should we add xid_current() or a int8->xid cast? |
Дата | |
Msg-id | CA+TgmoYDNXSQj-nEyNgH3WmD0gNepCVqgbrgjrDt2fxLzAVUsQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should we add xid_current() or a int8->xid cast? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Should we add xid_current() or a int8->xid cast?
|
Список | pgsql-hackers |
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: