A patch cannot reorder inherited columns, and diff reports the resulting order difference as an opaque "columns changed" #240

Two problems that compound. The second is what makes the first expensive to diagnose.

1. diff's default output does not say the difference is column order

diff has -ignore-column-order, which is the right escape hatch and works. The problem is the message on the default path, which gives the reader nothing to act on.

Two materialized views with the same column set and the same types, differing only in the order the columns appear, diff as:

  ~ materialized_view kafka_trace_spans_avro_mv (UNSAFE: materialized view to_table or incompatible column list change requires recreating the view)
      ~ columns changed

No column is named, and nothing indicates ordering is the issue or that a flag covers it. Verified on the pair above: same 29 names, same 29 types, set(a) == set(b) true, list(a) == list(b) false — the sole difference is position.

That reads as a content difference, so the natural response is to go hunting for a type or a missing column, and there is none to find. A line like column order differs (see -ignore-column-order): expected uuid, …, name, kind, flags; got uuid, …, name, timestamp, end_time would end the investigation immediately.

plan has no -ignore-column-order at all, which is #241.

2. A patch cannot reorder inherited columns

patch_table and patch_materialized_view accept column blocks with a positional after, so a new column can be placed anywhere. There is no equivalent for a column the patch inherits: modify_column replaces the spec but not the position, and nothing moves an existing column.

So when two compositions share an object whose column order differs, the difference cannot be expressed as a patch at all. The only way through is restating the whole object with override = true — which copies the full column list to express an ordering difference, and copies are what the once-only rule exists to prevent.

The flag does not substitute for this. Ignoring order in the comparison is a reporting choice; it does not let the layers say what the order is.

Concretely: one node class runs a view whose SELECT is * EXCEPT (a, b, c), <a, b, c re-added>, another runs a version excepting a different set. Same columns, different order, and a patch cannot say so.

Suggestion

For (1), name the columns and say "order differs" when the sets match, and point at -ignore-column-order — cheap, and it turns a dead-end message into a finished diagnosis.

For (2), either accept after on modify_column, or add an explicit column_order = [...] to the patch specs. Either lets an ordering difference be a patch instead of a copy.

Found while giving the apm role its own layers: four views differ from the logs role's only in to_table and became one-line patches after #239, while two more differ only in column order and still have to be restated in full.