The proxy mistakes triggers for columns? Proxy seems too restrictive.

[gorbak25]

For this migration:

CREATE OR REPLACE FUNCTION toposort_datatable_inserted() RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO public."DataTableTopoColumnOrder"(table_id, toposort) 
  SELECT id, array[]::uuid[] FROM inserted;
RETURN NEW;
END;
$$ LANGUAGE plpgsql
   SET search_path TO public;
CREATE OR REPLACE TRIGGER trigger_0000_toposort_table_data_table_insert 
AFTER INSERT ON public."DataTable"
REFERENCING NEW TABLE AS inserted
FOR EACH STATEMENT
EXECUTE FUNCTION public.toposort_datatable_inserted();
ALTER TABLE "DataTable" ENABLE ALWAYS TRIGGER trigger_0000_toposort_table_data_table_insert;

The proxy fails and returns:

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 20230927234059_toposort_trigger

Database error code: EX004

Database error:
ERROR: Cannot alter column "trigger_0000_toposort_table_data_table_insert" of electrified table "public"."DataTable"

DbError { severity: "ERROR", parsed_severity: None, code: SqlState(Other("EX004")), message: "Cannot alter column \"trigger_0000_toposort_table_data_table_insert\" of electrified table \"public\".\"DataTable\"", detail: None, hint: None, position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: None, line: Some(1), routine: None }

Looks like I will need to split my migrations into 2 separate parts, one applied via the proxy, the second one applied directly via postgres :smiley:

[magnetised]

@gorbak25 interesting, thanks for the report. We seem to be interpreting this alter table ... add trigger as some kind of problem, though in reality it's not. I can add handling of that case to allow this.

[gorbak25]

@magnetised Thank you!