Views that rely on GROUP BY functional dependency (e.g., SELECT col FROM t GROUP BY t.id where id is the PK) fail during schema restore because primary key constraints are restored after views.
parseDump extracts primary key constraints into the indicesAndConstraints section, but views remain in the filtered section which is restored first. Without the PK existing on the target, PostgreSQL can't verify the functional dependency and rejects the view with a GROUP BY error.
Current restore order:
- Schemas → 2. Cleanup → 3. Roles → 4. Filtered schema (tables + views) → 5. Data → 6. Sequences → 7. Indices & constraints (PKs)
Fix: Extract views from the filtered dump and restore them after indices/constraints, when PKs exist.
Views that rely on GROUP BY functional dependency (e.g.,
SELECT col FROM t GROUP BY t.idwhereidis the PK) fail during schema restore because primary key constraints are restored after views.parseDumpextracts primary key constraints into theindicesAndConstraintssection, but views remain in thefilteredsection which is restored first. Without the PK existing on the target, PostgreSQL can't verify the functional dependency and rejects the view with a GROUP BY error.Current restore order:
Fix: Extract views from the filtered dump and restore them after indices/constraints, when PKs exist.