In #148694, we removed the downgradeType function, which was invoked during protobuf serialization of types.T objects. This function was initially created to preserve compatibility with our pre-19.1 type formats in a mixed version setting. This removal was done during the 25.4 development cycle. There's a corresponding upgradeType function that is invoked during deserialization.

Due to the way that upgradeType and downgradeType had been implemented previously (i.e. in pre-19.1 versions), we needed to keep the VisibleType field of the protobuf, even though that is part of the legacy format. The reason is that in versions 25.3 (and earlier) upgradeType will look at the VisibleType and use that to overwrite the Oid field:

In v25.4 we've added logic to avoid overwriting the OID if it's already present. Here's the same section of the code in 25.4:

If the cluster is in a mixed version state and has both v25.4 and v25.3 nodes, then we need to make sure VisibleType is still present -- otherwise the correct OID will get clobbered during deserialization.

Once we no longer need compatibility with 25.3 or earlier, we can safely remove VisibleType entirely. We may be able to remove upgradeType as well.

update: we re-added some of downgradeType in v25.4 (#154363), but it should still be safe to remove after the v25.4 upgrade.

Jira issue: CRDB-53950

Epic CRDB-58150