sql: add jsonpath type

[normanchenn]

As part of work to implement jsonpath queries, this PR implements thejsonpath type within CockroachDB. There is no parsing or evaluation added, and the jsonpath will currently accept any non-empty string. Indexes are not currently supported for jsonpath columns.

Part of: #22513
Release note (sql change): Adding jsonpath type, without parsing or evaluation. Currently accepts any non-empty string.

[cockroach-teamcity]

This change is 

[yuzefovich]

Nice! Looks like there are only a handful of failures left. On a quick glance I only spotted one issue.

Reviewed 4 of 67 files at r1.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @normanchenn)

---

pkg/sql/catalog/colinfo/column_type_properties.go line 52 at r1 (raw file):

		types.JsonFamily,
		types.CollatedStringFamily,
		types.JsonpathFamily:

nit: this should be false for jsonpath. "Composite key encoding" is a special concept for some data types where different values of that type might have the same key encoding, yet we need to store them differently (for example, 0::FLOAT and -0::FLOAT are equal to each other, so they must have the same key encoding - used when building forward indexes - yet we need to differentiate the two). Jsonpath will only have value encoding (at least initially), so compositeness of key is not applicable to it.

[normanchenn]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @normanchenn and @yuzefovich)

---

pkg/sql/distsql_physical_planner.go line 360 at r7 (raw file):

Previously, yuzefovich (Yahor Yuzefovich) wrote…

Do you remember what prompted this addition? The fact that we don't have an encoding? Consider adding a comment explaining the reason for why we need to disable distsql.

Yeah, there were some distsql tests that failed because we need an encoding (see https://mesolite.cluster.engflow.com/invocations/default/28df9356-d045-490d-9413-c993df93d3a2) - added a comment as well

---

pkg/sql/catalog/colinfo/col_type_info.go line 110 at r7 (raw file):

Previously, yuzefovich (Yahor Yuzefovich) wrote…

I think if you remove this addition here, we won't need to make any changes in create_table.go to disallow columns of this type - we should fall back to the default case below.

Done.

[yuzefovich]

Nice work figuring all the things out! I have a couple more nits, but they are non-blocking, so

Reviewed 15 of 15 files at r8, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @normanchenn)

---

pkg/sql/catalog/colinfo/col_type_info.go line 155 at r8 (raw file):

// ColumnTypeIndexesAreSupported returns whether indexes are supported for type t.
func ColumnTypeIndexesAreSupported(t *types.T) bool {

nit: this function is no longer used. (The linter in the CI doesn't complain because it is exported.)

---

pkg/sql/sem/tree/type_check.go line 3817 at r8 (raw file):

// the relevant comparison overloads because we rely on their existence in
// various locations throughout the codebase.
func checkJsonpathComparison(op treecmp.ComparisonOperatorSymbol, left, right *types.T) error {

nit: should we refactor existing checkRefCursorComparison to be the shared helper that would take an extra argument (either RefCursor of Jsonpath type) to indicate which one we're validating? For example, this will ensure that we also will check tuples for containing jsonpath (which we currently don't do).

[normanchenn]

TFTR!

bors r+

[craig]

Build failed (retrying...):

• check_generated_code

[craig]

Build failed (retrying...):

• check_generated_code

[msbutler]

bors r-

looks like this failed the check generated code check

[craig]

Canceled.

[normanchenn]

bors r+

[craig]

Build succeeded:

• docker_image_amd64
• local_roachtest
• unit_tests
• linux_amd64_build
• acceptance
• linux_amd64_fips_build
• lint
• examples_orms
• local_roachtest_fips
• check_generated_code