make polymorphic variadic builtin functions heterogeneous

[mw5h]

tree: polymorphic variadic builtin functions are now heterogeneous

Previously, builtin functions with the parameter type VariadicType{VarType: types.Any} required that all variable arguments have the same type. This is what Postgres documents as its behavior, but the reality is that Postgres polymorphic builtins accept any heterogeneous arguments. This patch changes our overload handling to allow heterogeneous arguments to CRDB builtins.

Fixes: #136295
Release notes (bug fix): PREPARE now accepts heterogeneous arguments to the concat, json_build_object, jsonb_build_object, json_build_array, jsonb_build_array functions.

builtins: support polymorphic variadic arguments in concat_ws()

Previously, concat_ws took a variable length argument list of strings. Postgres allows anyelement data types for concat_ws(). Rewrite concat_ws() so that it takes a fixed string first argument followed by a variable list of anyelement arguments.

Release note (sql change): The concat_ws builtin function will now accept non-string arguments in the second and later positions.

[cockroach-teamcity]

This change is 

[michae2]

Reviewed 7 of 7 files at r1, 4 of 4 files at r2.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @mw5h)

---

-- commits line 20 at r2:
after that slack conversation, I think we need to be careful about 'any' vs 'anyelement', and this should be 'any'

---

pkg/sql/pgwire/pgwirebase/encoding.go line 861 at r3 (raw file):

	}
	switch id {
	case oid.T_text, oid.T_varchar, oid.T_unknown, oid.T_anyelement:

does PG have a different oid type for any?

---

pkg/sql/sem/tree/overload.go line 1208 at r1 (raw file):

	if numOverloads == 1 {
		routineType, _, _ := s.overloads[0].outParamInfo()
		if vt, ok := s.params[0].(VariadicType); ok && vt.VarType == types.Any && routineType == BuiltinRoutine {

as discussed in slack, instead of checking routineType == BuiltinRoutine, we might want to divide types.Any from a new types.AnyElement, since they seem to be different pseudo-types in PG

---

pkg/sql/sem/tree/overload.go line 1429 at r1 (raw file):

		// operators).
		for i, ok := s.placeholderIdxs.Next(0); ok; i, ok = s.placeholderIdxs.Next(i + 1) {
			if s.typedExprs[i] != nil && heterogeneousBuiltin {

Do we need this check? (since homogeneousTyp is set to nil when heterogeneousBuiltin is set to true)

[mw5h]

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

---

pkg/sql/pgwire/pgwirebase/encoding.go line 861 at r3 (raw file):

Previously, michae2 (Michael Erickson) wrote…

does PG have a different oid type for any?

Yeah, oid.T_any exists (in both code bases).

---

pkg/sql/sem/tree/overload.go line 1208 at r1 (raw file):

Previously, michae2 (Michael Erickson) wrote…

as discussed in slack, instead of checking routineType == BuiltinRoutine, we might want to divide types.Any from a new types.AnyElement, since they seem to be different pseudo-types in PG

Yikes. So, you're suggesting that we change the current types.Any into types.AnyElement and then introduce a new types.Any that is only used for builtin functions?

---

pkg/sql/sem/tree/overload.go line 1429 at r1 (raw file):

Previously, michae2 (Michael Erickson) wrote…

Do we need this check? (since homogeneousTyp is set to nil when heterogeneousBuiltin is set to true)

homgoneousTyp can be set again at line 1396. I frankly don't like that very much (I don't like to reassign variables if possible), but I'm a bit afraid to monkey too much with this code because the knock-on effects can be subtle.