opt: use only required columns in provided ordering for project

Project operators can only pass through their input ordering.
However, the provided ordering may have to be remapped in order to
ensure it only refers to output columns, since the `Project` can add
and remove columns. The `Project` uses its `internalFDs` field to
accomplish the remapping; these are constructed when the `Project`
is added to the memo by combining the functional dependencies of the
input and the projections.

The problem occurs when transformation rules cause the input of the
`Project` to "reveal" additional functional dependencies. For example,
one side of a union may be eliminated and the FDs of the remaining side
used in the result. This can cause the `Project` to output an ordering
that is equivalent to the required ordering according to its own FDs,
but which a parent operator cannot tell is equivalent because its FDs
were calculated before the tranformation rule fired. This can cause
panics later down the line when the provided ordering does not match
up with the required ordering.

In the following example, an exploration rule transforms the join into
two joins unioned together, one over each disjunct. After the
transformation, a normalization rule fires that removes the
`t0.rowid IS NULL` side because rowids are non-null. This reveals the
`t1.rowid = t0.rowid` FD, which later causes `t0.rowid` to be used in
a provided ordering rather than `t1.rowid`. For the reasons mentioned
above, this later causes a panic when a `Project` attempts to remap to
the required `t1.rowid` ordering.
```
CREATE TABLE t0 (c0 INT);
CREATE TABLE t1 (c0 INT);

SELECT * FROM t0 CROSS JOIN t1
WHERE (t0.rowid IS NULL) OR (t1.rowid IN (t0.rowid))
ORDER BY t1.rowid;
```

This commit prevents the panic by making `Project` operators remap the
input provided ordering to use columns from the required ordering
(which are a subset of the output columns). This prevents the disparity
between required and provided orderings that can cause panics down the
line. In the example given above, the `t1.rowid` column would be chosen
for the provided ordering because it is in the required ordering.

Fixes cockroachdb#85393

Release note (bug fix): fixed a vulnerability in the optimizer that could
cause a panic in rare cases when planning complex queries with `ORDER BY`.

Release justification: low-risk bug fix

pkg/sql/opt/ordering/project.go

@@ -14,6 +14,7 @@ import (
 	"github.com/cockroachdb/cockroach/pkg/sql/opt"
 	"github.com/cockroachdb/cockroach/pkg/sql/opt/memo"
 	"github.com/cockroachdb/cockroach/pkg/sql/opt/props"
+	"github.com/cockroachdb/errors"
 )
 
 func projectCanProvideOrdering(expr memo.RelExpr, required *props.OrderingChoice) bool {
@@ -74,13 +75,24 @@ func projectOrderingToInput(
 }
 
 func projectBuildProvided(expr memo.RelExpr, required *props.OrderingChoice) opt.Ordering {
-	p := expr.(*memo.ProjectExpr)
+	// Ensure that the child provided ordering only refers to columns from the
+	// required ordering choice. This is necessary because there may be cases
+	// where the input of the Project has undergone transformations that allow it
+	// to "see" more functional dependencies than the original memo group. This
+	// can cause the child to provide an ordering that is equivalent to the
+	// required ordering, but which the parent Project cannot prove is equivalent
+	// because its FDs have less information. This can lead to a panic later on.
+	ordCols := required.ColSet()
+	if !ordCols.SubsetOf(expr.Relational().OutputCols) {
+		panic(errors.AssertionFailedf("expected required columns to be a subset of output columns"))
+	}
 	// Project can only satisfy required orderings that refer to projected
 	// columns; it should always be possible to remap the columns in the input's
 	// provided ordering.
+	p := expr.(*memo.ProjectExpr)
 	return remapProvided(
 		p.Input.ProvidedPhysical().Ordering,
 		p.InternalFDs(),
-		p.Relational().OutputCols,
+		ordCols,
 	)
 }

pkg/sql/opt/xform/testdata/physprops/ordering

@@ -2511,3 +2511,41 @@ project
       │         ├── name:2 = name:8 [outer=(2,8), fd=(2)==(8), (8)==(2)]
       │         └── k:7::STRING = lower(name:8) [outer=(7,8), immutable]
       └── 56
+
+# Regression test for #85393 - use only columns from the required ordering when
+# building the provided ordering for Project operators.
+exec-ddl
+CREATE TABLE t0_85393 (c0 INT);
+----
+
+exec-ddl
+CREATE TABLE t1_85393 (c0 INT);
+----
+
+opt
+SELECT *
+FROM t0_85393 CROSS JOIN t1_85393
+WHERE (t0_85393.rowid IS NULL) OR (t1_85393.rowid IN (t0_85393.rowid))
+ORDER BY t1_85393.rowid;
+----
+sort
+ ├── columns: c0:1 c0:5  [hidden: t1_85393.rowid:6!null]
+ ├── fd: (6)-->(5)
+ ├── ordering: +6
+ └── project
+      ├── columns: t0_85393.c0:1 t1_85393.c0:5 t1_85393.rowid:6!null
+      ├── fd: (6)-->(5)
+      └── inner-join (cross)
+           ├── columns: t0_85393.c0:1 t0_85393.rowid:2!null t1_85393.c0:5 t1_85393.rowid:6!null
+           ├── key: (2,6)
+           ├── fd: (2)-->(1), (6)-->(5)
+           ├── scan t0_85393
+           │    ├── columns: t0_85393.c0:1 t0_85393.rowid:2!null
+           │    ├── key: (2)
+           │    └── fd: (2)-->(1)
+           ├── scan t1_85393
+           │    ├── columns: t1_85393.c0:5 t1_85393.rowid:6!null
+           │    ├── key: (6)
+           │    └── fd: (6)-->(5)
+           └── filters
+                └── (t0_85393.rowid:2 IS NULL) OR (t1_85393.rowid:6 = t0_85393.rowid:2) [outer=(2,6)]