Adding a column to a table fails when dependent views use `SELECT *`

[KrisBraun]

When a table gains a new column and a dependent view uses SELECT t.*, pgschema emits CREATE OR REPLACE VIEW which fails because PostgreSQL cannot rename existing view columns.

Reproduction

Given:

CREATE TABLE item (
  id uuid PRIMARY KEY,
  title text,
  status text
);

CREATE VIEW item_extended AS
  SELECT i.*, c.name AS category_name
  FROM item i JOIN category c ON ...;

Now add a column to the table:

-- In desired state SQL:
CREATE TABLE item (
  id uuid PRIMARY KEY,
  title text,
  status text,
  new_col text   -- added
);

pgschema detects item_extended needs updating (because i.* now includes new_col) and emits:

CREATE OR REPLACE VIEW item_extended AS
  SELECT i.*, c.name AS category_name FROM ...;

This fails with:

ERROR: cannot change name of view column "category_name" to "new_col" (SQLSTATE 42P16)

The i.* expansion now includes new_col before category_name, shifting column positions. PostgreSQL's CREATE OR REPLACE VIEW does not allow renaming existing columns.

Expected behavior

When a view's column set changes (not just the query body), pgschema should DROP VIEW + CREATE VIEW instead of CREATE OR REPLACE VIEW. This may require cascading drops for dependent views, which should be recreated afterward.

Impact

This blocks routine schema changes (adding columns to core tables) from being applied automatically. Any table referenced by views using SELECT * is affected.