sql: deprecate ordinal column references

[mgartner]

sql: deprecate ordinal column references

This commit disallows ordinal column references by default. Any
statements using them will result in an error. The session setting
allow_ordinal_column_references can be set to true to revert to
previous behavior.

Note that numeric tuple indexing (e.g., SELECT ((1,2,3)).@2) is still
allowed.

This deprecation is motivated by the inconsistent and surprising
behavior that ordinal column references provide. Ordinal column
references (e.g., SELECT @1 FROM t) are a vestigial and undocumented
feature originally motivated to aid the heuristic planner. The PR that
added them, #10729, discourages their use by users because "they are not
robust against schema changes". It also points out a subtle difference
between ordinal column references and SQL standard ordinals that could
confuse users. As an example, the following statements are not
equivalent:

SELECT @2 FROM t ORDER BY @1;

SELECT @2 FROM t ORDER BY 1;

In the current implementation, an ordinal column reference @n resolves
to the n-th column in the current scope's slice of columns. This has
several implications:

1. Ordinal columns can refer to any column, not just columns of data
   sources in FROM clauses, as was originally intended. This makes it
   hard to reason about the resolution of an ordinal column reference.
   For example, it's somewhat surprising that the result of the SELECT
   below is not (10, 1).

CREATE TABLE t (a INT, b INT);
INSERT INTO t VALUES (1, 10);

SELECT @2, @1 FROM (SELECT @2, @1 FROM t);
  ?column? | ?column?
-----------+-----------
         1 |       10
(1 row)

2. The ordering of columns in the scope's slice is not guaranteed to be
   consistent, so any reasonable ordinal column resolution occurs
   more-or-less by chance. As an example of unexpected behavior,
   consider:

CREATE TABLE t (a INT PRIMARY KEY, INDEX ((a+10)));
INSERT INTO t(a) VALUES (1);
ALTER TABLE t ADD COLUMN b INT;

SELECT @1, @2 FROM t;
  ?column? | ?column?
-----------+-----------
         1 |       11
(1 row)

Most users would expect the result of the SELECT statement to be
(1, NULL) because @1 should resolve to a and @2 should resolve
to b. Instead, the ordinal column reference @2 circumvents logic
that keeps inaccessible columns from being referenced, and resolves to
the virtual computed column backing the secondary index.

Epic: None

Release note (sql change): Ordinal column references (e.g.,
SELECT @1, @2 FROM t) are now deprecated. By default, statements using
this syntax will now result in an error. They can be allowed using the
session setting SET allow_ordinal_column_references=true. Support for
ordinal column references is scheduled to be removed in version 23.2.

[cockroach-teamcity]

This change is 

[knz]

Huh, but what feature then remains to select a column from a source by ordinal position? like "i want just the first column"

[knz]

also, what's the motivation for this change generally?

[knz]

maybe I can still do select (t.*).@1 from t instead of select @1 from t?

[ajwerner]

Huh, but what feature then remains to select a column from a source by ordinal position? like "i want just the first column"

When does this come up?

[knz]

When does this come up?

• select @1 from pg_get_keywords() because I never remember the name
• select @2, @1 from ... to invert the order of columns after a join

NB I'm ok with the change if we don't deprecate the syntax (t.*).@N which achieves the same (as far as I can see)

[mgartner]

I've added an explanation of the motivation to the commit message.

[knz]

cheers that works for me 👍

[ajwerner]

Reviewed 37 of 37 files at r1, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @benbardin, @knz, and @rafiss)

[mgartner]

TFTRs!

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)