I'm attempting to modify a schema where dependent tables weren't set up to cascade on delete. This seems like it should be a simple change, but it isn't, and I'm wondering if the SQL console can give me an "I know what I'm doing" escape hatch in the form of running an arbitrary query, then resyncing metadata after the query completes?

Essentially, my SQL looks like this:

BEGIN;
ALTER TABLE ONLY public.ocr_job
    DROP CONSTRAINT ocr_job_output_id_fkey,
    ADD CONSTRAINT ocr_job_output_id_fkey FOREIGN KEY (output_id) REFERENCES public.output(id) ON UPDATE CASCADE ON DELETE CASCADE;
...
COMMIT;

I've ensured that all foreign key names are preserved, and that they're modified in a transaction.

Unfortunately, running this migration in the console wants me to destroy and recreate relationships, permissions, etc. and there are quite a few. I'd understand the above restrictions if I was arbitrarily running SQL and not being cautious, but it seems to me like this shouldn't cause an issue.

If I run this SQL directly on the psql console, then refresh metadata in the console, my changes seem to get picked up and represented accurately. I don't know Hasura well enough to know if something is broken and I just haven't found it yet, but this seems like a case where the console is fighting me, and I hope it has a good reason to do so. :)

It also looks as if I'll have to wipe out our database, start with an initial migration with the current state, then religiously ensure that cascades are correctly set going forward.

Can we get some sort of escape hatch? :) And as an aside, is there some other way to fix this without starting over?

Thanks.