> On Apr 6, 2020, at 5:14 PM, Thomas Munro <thomas.mu...@gmail.com> wrote:
>
> On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro <thomas.mu...@gmail.com> wrote:
>> On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
>> <mark.dil...@enterprisedb.com> wrote:
>>> The "xid8_" warts are partly motivated by having a type named "xid8", which
>>> is a bit of a wart in itself.
>>
>> Just a thought for the future, not sure if it's a good one: would it
>> seem less warty in years to come if we introduced xid4 as an alias for
>> xid, and preferred the name xid4? Then it wouldn't look so much like
>> xid is the "real" transaction ID type and xid8 is some kind of freaky
>> extended version; instead it would look like xid4 and xid8 are narrow
>> and wide transaction IDs, and xid is just a historical name for xid4.
>
> I'll look into proposing that for PG14. One reason I like that idea
> is that system view names like backend_xid could potentially retain
> their names while switching to xid8 type, (maybe?) breaking fewer
> queries and avoiding ugly names, on the theory that _xid doesn't
> specify whether it's xid4 or an xid8.
>
>>>> pg_current_xact_id()
>>>> pg_current_xact_id_if_assigned()
>>>> pg_xact_status(xid8)
>
>>>> pg_current_snapshot()
>>>> pg_snapshot_xmin(pg_snapshot)
>>>> pg_snapshot_xmax(pg_snapshot)
>>>> pg_snapshot_xip(pg_snapshot)
>>>> pg_visible_in_snapshot(xid8, pg_snapshot)
>
>>> As such, I'm ±0 for the change.
>>
>> I'll let this sit for another day and see if some more reactions appear.
>
> Hearing no objections, pushed. Happy to reconsider these names before
> release if someone finds a problem with this scheme.
Hmm, I should have spoken sooner...
src/backend/replication/walsender.c:static bool
TransactionIdInRecentPast(TransactionId xid, uint32 epoch);
src/backend/utils/adt/xid8funcs.c:TransactionIdInRecentPast(FullTransactionId
fxid, TransactionId *extracted_xid)
I don't care much for having two different functions with the same name and
related semantics but different argument types.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
