[FIX] lift_constraints: drop constraints individually, not in one statement

[quoc-pn]

Bug

lift_constraints() drops all constraints found on a column in a single ALTER TABLE ... DROP CONSTRAINT a, DROP CONSTRAINT b, ... statement.

On PostgreSQL 17+, NOT NULL is catalogued as a named constraint (<table>_<column>_not_null) instead of an implicit pg_attribute flag. PostgreSQL validates each DROP CONSTRAINT subcommand against the catalog state as it existed before the statement started, not against the pending effects of earlier subcommands within the same statement.

So when a column has both a not-null constraint and a primary key, and the not-null constraint happens to be listed before the primary key in the generated statement, PostgreSQL rejects the whole statement:

ERROR: column "id" is in a primary key

even though the very next clause in that same statement would have dropped the primary key.

This surfaced concretely in an OCA/OpenUpgrade migration script (hr_recruitment/19.0.1.1/pre-migration.py) calling lift_constraints(cr, legacy_table, "id", cascade=True) on a table whose id column has both a not-null constraint and a primary key, running against PostgreSQL 18.

Fix

Drop each constraint in its own separate ALTER TABLE ... DROP CONSTRAINT IF EXISTS ... statement instead of combining them into one multi-clause statement. This removes any cross-clause catalog ordering dependency, regardless of how many constraints are found or what order they come back in.

Test

The existing test_lift_constraints test (tests/test_openupgradelib.py) already exercises cascade=True on res_partner.id, which has both a primary key and (on PostgreSQL 17+) a not-null constraint — this test reproduces the failure before the fix and passes after it.

[hbrunn]

the huge slab of generated bullshit text is just that. the only actual fix here is getting the order right, which should be better done by generating the correct order via pg_depend