sql: fix UDF with VOID return type

[mgartner]

Functions with VOID returns types should be allowed to produce any
number of columns of any type from their last statement. Prior to this
commit, a calling UDF with a VOID return type would error if the last
statement in the UDF did not produce a value of type VOID. This commit
fixes this minor bug.

Fixes #108297

Release note (bug fix): The last SQL statement in a user-defined
function with a VOID return type can now produce any number of columns
of any type. This bug was present since UDFs were introduced in version
22.2.

[cockroach-teamcity]

This change is 

[rharding6373]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball and @mgartner)

---

pkg/sql/opt/optbuilder/scalar.go line 736 at r1 (raw file):

		// column would be pruned and the contents of last statement would not
		// be executed.
		// TODO(mgartner): This will add some planning overhead for every

Would adding this statement in buildCreateFunction instead be more efficient? The main issue I see in that proposal is that we'd print the extra statement in show create function, unless we had some kind of annotation in place.

Alternatively, in cases where we don't inline the function, we could add some code to routine to execute all statements but return null at the end when the return type is void. I'm not sure what an alternative would be if we don't need to use routines, though, and I don't know if preventing inlining for void return types is worth it.

---

pkg/sql/logictest/testdata/logic_test/udf_regressions line 620 at r1 (raw file):

NULL

# Invoking the UDF above should have increment s108297 to 1, so calling nextval

Nice test.

[mgartner]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball and @rharding6373)

---

pkg/sql/opt/optbuilder/scalar.go line 736 at r1 (raw file):

Would adding this statement in buildCreateFunction instead be more efficient? The main issue I see in that proposal is that we'd print the extra statement in show create function, unless we had some kind of annotation in place.

It'd make it harder to change our implementation of RETURNS VOID in future releases because we'd have to update existing UDFs to remove the extra statement.

Alternatively, in cases where we don't inline the function, we could add some code to routine to execute all statements but return null at the end when the return type is void. I'm not sure what an alternative would be if we don't need to use routines, though, and I don't know if preventing inlining for void return types is worth it.

Ya, maybe this special logic for RETURNS VOID should be during evaluation of the routine - then it would add no overhead. I'll try that in a separate PR.

[DrewKimball]

Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @mgartner and @rharding6373)

---

pkg/sql/opt/optbuilder/scalar.go line 769 at r1 (raw file):

			panic(err)
		}
		// TODO(#108298): Figure out how to handle PLpgSQL functions with VOID

We could also directly construct the Values expression, that would make it easier to handle PLpgSQL as well.

[mgartner]

TFTRs!

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)