Hi,
A composite datum records the OID and typmod of its row type and nothing
about the shape it was built with, so every value is read back against
whatever the type looks like currently at read time. Nothing prevents
the below for example:
CREATE TYPE ct AS (a int, b int);
CREATE TABLE t (v ct);
CREATE UNIQUE INDEX t_v ON t (v);
INSERT INTO t VALUES (ROW(1, 2)::ct), (ROW(1, 3)::ct); -- accepted
ALTER TYPE ct DROP ATTRIBUTE b; -- accepted today! this violates UNIQUE
SELECT count(DISTINCT v) FROM t;
1
The rows are on disk and were committed before the ALTER; no cursor or
plan is involved, and the incorrect reading survives a restart.
INSERT INTO t VALUES (ROW(1)::ct);
ERROR: duplicate key value violates unique constraint "t_v"
DETAIL: Key (v)=((1)) already exists.
REINDEX INDEX t_v;
ERROR: could not create unique index "t_v"
DETAIL: Key (v)=((1)) is duplicated.
Worse, a plain pg_dump of that database fails to restore for the
same reason.
The check for this exists. On the same table, before the drop, retyping
the attribute is refused:
ALTER TYPE ct ALTER ATTRIBUTE b TYPE bigint;
ERROR: cannot alter type "ct" because column "t.v" uses it
but the call is gated on a rewrite being queued,
if (tab->newvals != NIL || tab->rewrite > 0)
find_composite_type_dependencies(...);
and a drop produces neither, so it walks past.
The same applies to ALTER TABLE ... DROP COLUMN, since a table's row type
is a composite type too, and there too the retyping form is already
refused.
The attached patch calls the existing function from the drop path, after
the column is checked for droppability and before recursion to
inheritance children, so both calls and every level are covered.
Regression, isolation and pg_upgrade suites pass.
I added new tests and had to modify a couple of existing tests because of this
behavior change.
Regards,
Nikhil
---
Nikhil Sontakke
PlanetScale Postgres Core Team
