sql: compatibility blitz for pgadmin

[jordanlewis]

A bunch of small improvements to the catalog, new builtins, and a couple of typing improvements all in the name of making pgadmin work.

And it works okay now! Definitely still some flaws and unsupported things, but at least the default experience isn't completely broken anymore.

Closes #33341.
Closes #23299.
Closes #26389.
Closes #26378.
Closes #26390.
Closes #24747.
Closes #37124.
Updates #25213.

[cockroach-teamcity]

This change is 

[awoods187]

Awesome! This is really great stuff!

[RaduBerinde]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis)

---

pkg/sql/opt/optbuilder/union.go, line 34 at r17 (raw file):

	// Try to propagate types left-to-right, if we didn't already have desired
	// types.
	if len(desiredTypes) == 0 {

Please add a new test for this in optbuilder/testdata/union

---

pkg/sql/sem/builtins/builtins.go, line 2246 at r15 (raw file):

	),

	"row_to_json": makeBuiltin(defProps(),

Can you add a logic test for this function?

[andy-kimball]

Amazing work, Jordan. This gives further evidence that there's a lot of low-hanging compatibility fruit across various drivers/tools that dedicated engineer(s) could pluck.

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis)

[jordanlewis]

Main questionable thing about this is that our type system is a little bit different than Postgres, so when we added the constant upcast path from string to string array, it causes a bad error message to be created for something like

SELECT array['foo'] || bar. Postgres also errors on this if you don't specify bar::text. But we produce something like no valid overload from string[] || string, which is a lie. The reason it produces this is that our typing rules apply in a particular order - we end up filtering out the string[]||string overload early in the case of not knowing the second string's type (it's a constant) because of this rule where we try to type constants homogeneously with resolved types, and throw away the ones that didn't match that. Then, we reject string[]||string[] because the second string can't resolve to a string[] as it doesn't parse to one.

I think the solution would be to change the homogeneous rule to prefer homogeneous but not rule out non-homogeneous, but I think that would be pretty invasive. I'm tempted to leave this bad error message for now.

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

---

pkg/sql/opt/optbuilder/union.go, line 34 at r17 (raw file):

Previously, RaduBerinde wrote…

Please add a new test for this in optbuilder/testdata/union

Done.

---

pkg/sql/sem/builtins/builtins.go, line 2246 at r15 (raw file):

Previously, RaduBerinde wrote…

Can you add a logic test for this function?

Done.

[jordanlewis]

@RaduBerinde feeling good about your stamp here? I'm ready to merge this.

[RaduBerinde]

Reviewable status: complete! 1 of 0 LGTMs obtained

[jordanlewis]

Thanks a lot for reviewing this!

bors r+

[craig]

Build succeeded

• GitHub CI (Cockroach)