DDL case sensitivity: ALTER COLUMN / DROP COLUMN accept mismatched column identifier case

[toga4]

The emulator resolves column identifiers referenced by ALTER TABLE ... ALTER COLUMN and ALTER TABLE ... DROP COLUMN case-insensitively, while Cloud Spanner requires the original case.

Related: #108 reported the same class of divergence for table identifiers and was closed as fixed. That fix does appear to cover table names in the current release (ALTER TABLE ACCOUNT ... against a table named Account correctly errors with Table not found: ACCOUNT on the emulator now), but the same treatment does not extend to column identifiers.

Per the docs:

When referring to other schema objects in a DDL statement (for example, a column name for a primary key, or table and column names in an index), make sure to use the original case for the name of each entity.

Reproduction

Image: gcr.io/cloud-spanner-emulator/emulator:latest (digest sha256:ad54472fe7b161b9214f7f816f304b649a4779e348229c375ac067f5ed5a6422, corresponds to v1.5.55).

Setup:

CREATE TABLE TableA (Id STRING(MAX) NOT NULL, MyColumn STRING(MAX) NOT NULL) PRIMARY KEY(Id);
CREATE TABLE TableB (Id STRING(MAX) NOT NULL, MyColumn STRING(MAX) NOT NULL) PRIMARY KEY(Id);

Statements that reference the column with the wrong case:

-- (A) ALTER
ALTER TABLE TableA ALTER COLUMN MYCOLUMN STRING(MAX);

-- (B) DROP
ALTER TABLE TableB DROP COLUMN MYCOLUMN;

Expected (Cloud Spanner behavior)

Both statements fail:

ERROR: Column not found in table TableA: MYCOLUMN
ERROR: Column not found in table TableB: MYCOLUMN

The schema and INFORMATION_SCHEMA.COLUMNS remain unchanged (MyColumn).

Actual (Emulator behavior)

Both statements succeed and mutate the MyColumn column:

• (A) TableA.MyColumn becomes nullable (the NOT NULL is dropped).
• (B) TableB.MyColumn is dropped.

Resulting schema on the emulator:

CREATE TABLE TableA (
  Id STRING(MAX) NOT NULL,
  MyColumn STRING(MAX),
) PRIMARY KEY(Id);

CREATE TABLE TableB (
  Id STRING(MAX) NOT NULL,
) PRIMARY KEY(Id);

Impact

CI that runs DDL against the emulator passes, but the same DDL fails when applied to Cloud Spanner. This surfaces most often when a schema was originally created with one case (e.g. MyColumn) and later maintenance uses another (e.g. MYCOLUMN).