smith: add all argument columns to ORDER BY

[DrewKimball]

This commit ensures that sqlsmith adds all function argument columns to
the ORDER BY clause when nondetermistic functions are disabled. This is
necessary for functions like string_agg, for which there may be multiple
possible values for each argument when the order is not specified.

As a special case, lead and lag require all input columns to be added
to the ORDER BY clause. This is because while they respect the specified
order, they can still access any value in the partition. This means that we
need to uniquely specify which rows fall on the boundaries of each peer group.
We can ensure this is the case by ordering on a key, and we can trivially
order on a key by ordering on all columns.

Partially addresses #85318
Fixes #87023

Release justification: testing-only change

Release note: None

[cockroach-teamcity]

This change is 

[yuzefovich]

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

---

-- commits line 16 at r1:
nit: this will close the issue - is it desirable? If not, maybe do s/fixes/addresses/.

[DrewKimball]

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

---

-- commits line 16 at r1:

Previously, yuzefovich (Yahor Yuzefovich) wrote…

nit: this will close the issue - is it desirable? If not, maybe do s/fixes/addresses/.

Done.

[DrewKimball]

TFTR!

[mgartner]

Nice find!

[DrewKimball]

Thanks!
bors r+

[craig]

Build failed:

• Bazel Essential CI (Cockroach)

[DrewKimball]

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[mgartner]

@DrewKimball Do you think the lead/lag special case mentioned about would also apply to other aggregates, like concat_agg? It seems like that might be causing failures like this one: #87335 (comment) and this one: #87353 (comment).

[DrewKimball]

Now that you mention it, I think it's better to think in terms of what window functions don't need to order on a key - rank and dense_rank should be ok, since the result is always the same within a peer group. I think basically everything else (including aggregate functions) needs to be ordering on a key - anything that doesn't explicitly return the same value for every row in a given peer group. As an example, row_number obviously will care if the ith row is switched with the (i-1)th row. Many aggregate functions are order-agnostic, but they respect window frames, which are not order-agnostic (in general).