sql: allow stars inside view definitions

[knz]

First commit from #97544.
Fixes #10028.

Release note (sql change): It is now possible to use * inside CREATE VIEW. The list of columns is expanded at the time the view is created, so that new columns added after the view was defined are not included in the view. This behavior is the same as PostgreSQL.

[cockroach-teamcity]

This change is 

[knz]

I am noting how the stars inside ORDER BY and GROUP BY are preserved here. This means they are also perserved in UDFs.

I believe this is OK? But I think we need some semantic expert to double check. In any case, this choice is not specific to this PR so it should not block it.

[DrewKimball]

Reviewed 1 of 4 files at r1.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @ajwerner, @knz, @mgartner, and @rharding6373)

---

pkg/sql/opt/optbuilder/project.go line 151 at r1 (raw file):

					aliases, exprs := b.expandStar(e.Expr, inScope)
					if b.insideFuncDef || b.insideViewDef {

I think there's another case in Builder.buildDataSource that needs to be changed (see #96375).

---

pkg/sql/logictest/testdata/logic_test/views line 439 at r1 (raw file):

statement ok
CREATE VIEW star16 AS SELECT t1.a, t2.a AS a2 FROM t AS t1 JOIN t AS t2 ON t1.a IN (SELECT a FROM (SELECT * FROM t))

Could you also add the cases from #96375? (similar to the existing join test cases, but without aliases)

---

pkg/sql/logictest/testdata/logic_test/views line 486 at r1 (raw file):

Previously, knz (Raphael 'kena' Poss) wrote…

I am noting how the stars inside ORDER BY and GROUP BY are preserved here. This means they are also perserved in UDFs.

I believe this is OK? But I think we need some semantic expert to double check. In any case, this choice is not specific to this PR so it should not block it.

That's a good catch, and I think it's a bug.

[knz]

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

---

pkg/sql/opt/optbuilder/project.go line 151 at r1 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

I think there's another case in Builder.buildDataSource that needs to be changed (see #96375).

hum no that would be a regression - we currently allow views to reference subqueries withut an alias, so removing that here would be a regression from current behavior.

---

pkg/sql/logictest/testdata/logic_test/views line 439 at r1 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

Could you also add the cases from #96375? (similar to the existing join test cases, but without aliases)

i'll look into it.

---

pkg/sql/logictest/testdata/logic_test/views line 486 at r1 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

That's a good catch, and I think it's a bug.

i'll file an issue.

[knz]

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

---

pkg/sql/logictest/testdata/logic_test/views line 486 at r1 (raw file):

Previously, knz (Raphael 'kena' Poss) wrote…

i'll file an issue.

#97520

[knz]

RFAL

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

---

pkg/sql/opt/optbuilder/project.go line 151 at r1 (raw file):

Previously, knz (Raphael 'kena' Poss) wrote…

hum no that would be a regression - we currently allow views to reference subqueries withut an alias, so removing that here would be a regression from current behavior.

I double checked - we do not need the special case related to #96375 here because CREATE VIEW separately rejects duplicate column names, so if there's an ambiguity it will be prevented this way.

---

pkg/sql/logictest/testdata/logic_test/views line 439 at r1 (raw file):

Previously, knz (Raphael 'kena' Poss) wrote…

i'll look into it.

Done.

[rharding6373]

Very nice, thanks for all the test cases! I only have suggestions for a couple more.

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

---

pkg/sql/logictest/testdata/logic_test/views line 440 at r1 (raw file):

statement ok
CREATE VIEW star16 AS SELECT t1.a, t2.a AS a2 FROM t AS t1 JOIN t AS t2 ON t1.a IN (SELECT a FROM (SELECT * FROM t))

Could you please add the following tests (or similar) to make sure schema changes and dependencies are handled correctly?

statement ok
ALTER TABLE t ADD COLUMN c INT;

statement error
ALTER TABLE t DROP COLUMN b;

# we expect the columns in the view to be unchanged
statement ok
ALTER TABLE t RENAME COLUMN b TO d;

[DrewKimball]

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @ajwerner, @knz, and @mgartner)

---

pkg/sql/opt/optbuilder/project.go line 151 at r1 (raw file):

CREATE VIEW separately rejects duplicate column names

I think this will only apply to the top-level columns returned by the view, but it seems ok anyway since apparently views bind differently from UDFs: #96375 (comment)

---

pkg/sql/logictest/testdata/logic_test/views line 468 at r3 (raw file):

# This error is the same as in postgres.

[nit] postgres gives subquery in FROM must have an alias, so not the same error here.

[knz]

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @ajwerner, @DrewKimball, @mgartner, and @rharding6373)

---

pkg/sql/opt/optbuilder/project.go line 151 at r1 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

CREATE VIEW separately rejects duplicate column names

I think this will only apply to the top-level columns returned by the view, but it seems ok anyway since apparently views bind differently from UDFs: #96375 (comment)

I investigated this further and we have indeed an 'interesting' situation here:

select array[z.*]::string from (select * from (select a from t), (select a from t)) z;

This example is interesting because there's just 1 unambiguous "outer" column, but we need to be careful "in the middle".

With my current code, we get invalid behavior as follows:

[email protected]:26257/movr> show create view v;
  table_name |                                       create_statement
-------------+-----------------------------------------------------------------------------------------------
  v          | CREATE VIEW public.v (
             |     "array"
             | ) AS SELECT
             |         ARRAY[z.*]::STRING
             |     FROM
             |         (SELECT a, a FROM (SELECT a FROM movr.public.t), (SELECT a FROM movr.public.t)) AS z
(1 row)

Time: 9ms total (execution 9ms / network 0ms)

[email protected]:26257/movr> select * from v;
ERROR: column reference "a" is ambiguous (candidates: <anonymous>.a)
SQLSTATE: 42702

Which means my PR needs to solve a subset of #96375 before we consider the job done.

---

pkg/sql/logictest/testdata/logic_test/views line 440 at r1 (raw file):

Previously, rharding6373 (Rachael Harding) wrote…

Could you please add the following tests (or similar) to make sure schema changes and dependencies are handled correctly?

statement ok
ALTER TABLE t ADD COLUMN c INT;

statement error
ALTER TABLE t DROP COLUMN b;

# we expect the columns in the view to be unchanged
statement ok
ALTER TABLE t RENAME COLUMN b TO d;

Done.

---

pkg/sql/logictest/testdata/logic_test/views line 468 at r3 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

[nit] postgres gives subquery in FROM must have an alias, so not the same error here.

Good point. Changed to add a test using pg's syntax.

[knz]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @ajwerner, @DrewKimball, @mgartner, and @rharding6373)

---

pkg/sql/opt/optbuilder/project.go line 151 at r1 (raw file):

Previously, knz (Raphael 'kena' Poss) wrote…

I investigated this further and we have indeed an 'interesting' situation here:

select array[z.*]::string from (select * from (select a from t), (select a from t)) z;

This example is interesting because there's just 1 unambiguous "outer" column, but we need to be careful "in the middle".

With my current code, we get invalid behavior as follows:

[email protected]:26257/movr> show create view v;
  table_name |                                       create_statement
-------------+-----------------------------------------------------------------------------------------------
  v          | CREATE VIEW public.v (
             |     "array"
             | ) AS SELECT
             |         ARRAY[z.*]::STRING
             |     FROM
             |         (SELECT a, a FROM (SELECT a FROM movr.public.t), (SELECT a FROM movr.public.t)) AS z
(1 row)

Time: 9ms total (execution 9ms / network 0ms)

[email protected]:26257/movr> select * from v;
ERROR: column reference "a" is ambiguous (candidates: <anonymous>.a)
SQLSTATE: 42702

Which means my PR needs to solve a subset of #96375 before we consider the job done.

Rebased on top of #97544, which fixes this. PTAL.

[knz]

TFYRs!

bors r=DrewKimball,rharding6373

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)