On Tue, Apr 7, 2020 at 12:14 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
> > <mark(dot)dilger(at)enterprisedb(dot)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.
Here's a patch that renames xid to xid4, but I realised that we lack
the technology to create a suitable backwards compat alias. The
bigint/int8 keyword trick doesn't work here, because it would break
existing queries using xid as, for example, a function argument name.
Perhaps we could invent a new kind of type that is a simple alias for
another type, and is entirely replaced by the base type early in
processing, so that you can do type aliases without bigint-style
keywords. Perhaps all of this is not worth the churn just for a
neatnick project.