colinfo: add version gate for storing pg_lsn types

[otan]

We don't want mixed version clusters storing pg_lsn types, in case they need to rollback / older versions do not understand the type.

Informs #105130

Release note: None

[cockroach-teamcity]

This change is 

[rafiss]

do we also need to block queries that use this data type in a cast? (that's what we had to do for tsquery)

we need to teach the mixed version tests to not use this type too. see 4607a74 and fd09e18

[rafiss]

nit: no need to make a new cluster version. you can just use clusterversion.V23_2

[otan]

there is no V23_2 though, only V23_2Start.

[otan]

oh it's not in the const

[rafiss]

not gonna block this, but see my comment about cast expressions

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @otan, @renatolabs, and @smg260)

---

pkg/sql/logictest/testdata/logic_test/pg_lsn_mixed line 2 at r1 (raw file):

# LogicTest: local-mixed-22.2-23.1
# TODO(otan): add tests for mixed 23.1-23.2.

i've got this PR brewing #104994

---

pkg/sql/logictest/testdata/logic_test/pg_lsn_mixed line 5 at r1 (raw file):

statement error pg_lsn not supported until version 23.2
CREATE TABLE pg_lsn_table(id pg_lsn, val pg_lsn)

i feel like we also need logic for blocking pg_lsn in cast expressions (and a test), otherwise won't distsql get confused in a mixed version cluster?

[otan]

pkg/sql/logictest/testdata/logic_test/pg_lsn_mixed line 5 at r1 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

i feel like we also need logic for blocking pg_lsn in cast expressions (and a test), otherwise won't distsql get confused in a mixed version cluster?

i'll add a test; i've never had to add a mixed version test for casts before - not sure there's a great place to do that either

[rafiss]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @otan, @renatolabs, and @smg260)

---

pkg/sql/logictest/testdata/logic_test/pg_lsn_mixed line 5 at r1 (raw file):

Previously, otan (Oliver Tan) wrote…

i'll add a test; i've never had to add a mixed version test for casts before - not sure there's a great place to do that either

you can use this same logic test file. what would be the problem with that?

[otan]

pkg/sql/logictest/testdata/logic_test/pg_lsn_mixed line 5 at r1 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

you can use this same logic test file. what would be the problem with that?

sorry, i meant adding a version gate for "check you can't ever instantiate a pg_lsn instance anywhere distsql is used".

[otan]

bors r=rafiss

mergin' for now, will update mixed-version tests later

[rafiss]

sorry, i meant adding a version gate for "check you can't ever instantiate a pg_lsn instance anywhere distsql is used".

you don't need to do this. all we'd need is a gate for using pg_lsn in cast expressions. for an example, see the change in pkg/sql/sem/eval/cast.go in #90842

i've added two new items to your tracking issue in #105130

Version gate pg_lsn type in cast expressions
Add pgwire encoding tests for pg_lsn to pkg/cmd/generate-binary/main.go

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[otan]

Add pgwire encoding tests for pg_lsn to pkg/cmd/generate-binary/main.go

already there!

[otan]

oh wait, i changed the json but forgot to commit the generate-binary changes