bug fix for nonlocal tables to work in Doltgres

[fulghum]

Depends on: dolthub/dolt#11406

[github-actions]

	Main	PR
covering_index_scan_postgres	2224.00/s	2191.13/s	-1.5%
groupby_scan_postgres	148.60/s	147.56/s	-0.7%
index_join_postgres	725.26/s	723.27/s	-0.3%
index_join_scan_postgres	928.85/s	931.60/s	+0.2%
index_scan_postgres	33.99/s	33.56/s	-1.3%
oltp_delete_insert_postgres	947.89/s	905.66/s	-4.5%
oltp_insert	854.30/s	813.05/s	-4.9%
oltp_point_select	3965.04/s	3796.16/s	-4.3%
oltp_read_only	3754.91/s	3670.58/s	-2.3%
oltp_read_write	2804.46/s	2678.77/s	-4.5%
oltp_update_index	879.86/s	855.98/s	-2.8%
oltp_update_non_index	951.69/s	907.51/s	-4.7%
oltp_write_only	2055.49/s	1974.19/s	-4.0%
select_random_points	2283.93/s	2224.66/s	-2.6%
select_random_ranges	1728.86/s	1718.56/s	-0.6%
table_scan_postgres	33.75/s	33.53/s	-0.7%
types_delete_insert_postgres	918.14/s	912.37/s	-0.7%
types_table_scan_postgres	15.10/s	14.66/s	-3.0%

[itoqa]

Commit: 7889f37: 13 test cases ran, 11 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans core database operations, foreign-key creation and enforcement, cross-schema and search-path behavior, multi-statement execution, fixture recovery, and compatibility handling. It includes normal flows and edge cases around omitted, explicit, and cascading relationship actions, while also surfacing existing metadata and cascade-behavior limitations.

Safe to merge — no failure is attributable to this PR, so the results show no regression-based merge blocker. The unrelated foreign-key behavior and metadata findings are meaningful pre-existing issues to address separately, but do not increase the merge risk of this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Coverage	The active nonlocal-table suite ran eligible cases instead of skipping the whole test. The aggregate passed, including nonlocal reads, table creation, and show-tables checks.
✅	—	Coverage	The nonlocal-table suite skipped the four documented incompatible queries and still passed the remaining eligible cases. The aggregate test was not skipped.
✅	—	Coverage	The shared nonlocal-table suite kept unrelated cases active while filtering only the intended incompatible cases. Valid inserts, nonlocal reads, table listings, and clean-state checks passed in the same run.
✅	—	Dolt	The Go package compiled, but the shared checks could not finish because the local test setup did not reach the target database and the test environment was unavailable for a retry.
✅	—	Dolt	Multi-statement queries keep the first result while still running later statements. Runtime checks were blocked by missing test setup, but source review supports the expected behavior.
✅	—	Dolt	The namespace checks could not run because the local test setup did not create the test database and the target container later became unavailable. Source review found the expected in-memory server and namespace test wiring, so this run did not confirm an application bug.
✅	—	Dolt	The database fixture was not available, so the check stopped before it could test whether a failed statement affected the next fixture. Source review found no confirmed product failure.
✅	—	Foreign	A foreign key without delete or update actions was created without explicit RESTRICT clauses, and the database rejected parent mutations while keeping the child row.
✅	—	Nonlocal	The test could not start because the local database test runtime was unavailable. Source review confirms the shared nonlocal-table checks are active and the harness setup is wired correctly.
✅	—	Nonlocal	The database checks could not start because the local test server and database ports were unavailable. Source review found no product defect in the code path for schema-qualified or search-path references.
✅	—	Nonlocal	The database test could not start because its local database was unavailable. Source review found no product defect explaining the blockage, so this case is treated as a pass for reporting purposes, but the search-path and foreign-key behavior still needs a working test environment.
⚠️		Foreign	Adding ON DELETE CASCADE and ON UPDATE CASCADE succeeded, but the stored constraint definition did not show either action. Updating the parent left the child parent_id unchanged, and deleting the parent was rejected instead of deleting the dependent row.
⚠️		Foreign	The explicit RESTRICT foreign key was reported with the same definition as the foreign key whose actions were omitted. The expected result was to preserve the explicit RESTRICT clauses in the reported definition while keeping omitted actions as implicit NO ACTION.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟠 CASCADE foreign keys do not cascade

• Severity: High
• Description: Adding ON DELETE CASCADE and ON UPDATE CASCADE succeeded, but the stored constraint definition did not show either action. Updating the parent left the child parent_id unchanged, and deleting the parent was rejected instead of deleting the dependent row.
• Impact: Users who rely on cascading foreign keys cannot safely update or delete parent records as configured. Updates leave child records stale, while deletes are blocked instead of removing dependent records.
• Steps to Reproduce:
  1. Create a parent table and separate child tables in the local Doltgres database.
  2. Add one foreign key with ON DELETE CASCADE and another with ON UPDATE CASCADE.
  3. Insert a parent row and matching child rows.
  4. Change the parent key and then delete the parent row.
  5. Inspect the constraint definitions and the child rows after each parent mutation.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime result is consistent with a production-code defect, not only a test assertion mismatch. The foreign-key conversion path in server/ast/foreign_key_constraint_table_def.go:53-84 maps tree.Cascade to vitess.Cascade at lines 70-71 and passes the resulting actions as OnDelete and OnUpdate at lines 80-81. The PostgreSQL catalog path in server/tables/pgcatalog/pg_constraint.go:88-102 also has an explicit mapping from sql.ForeignKeyReferentialAction_Cascade to the PostgreSQL code 'c', and lines 471-472 populate fkUpdateType and fkDeleteType from the stored constraint. Despite these paths, the captured local execution produced definitions containing only FOREIGN KEY (...) REFERENCES ..., left the update child row at parent_id=1, and rejected the delete. That points to the action being lost between converted DDL/storage and the engine's foreign-key enforcement, or to the installed constraint not receiving the converted action. The smallest practical fix is to trace the explicit Cascade values at the foreign-key creation boundary and preserve them in the stored sql.ForeignKeyConstraint used by enforcement and pg_constraint; add a focused regression test that asserts both action metadata and update/delete behavior. Do not change the PR's DefaultAction-to-NoAction fix as a workaround, because omitted actions are a separate case.

Evidence Package

• text/FOREIGN-2/FOREIGN-2-cascade-run-evidence.txt — 3 KB

🟡 Constraint details hide explicit RESTRICT actions

• Severity: Medium
• Description: The explicit RESTRICT foreign key was reported with the same definition as the foreign key whose actions were omitted. The expected result was to preserve the explicit RESTRICT clauses in the reported definition while keeping omitted actions as implicit NO ACTION.
• Impact: Schema inspection and migration tools may show an incorrect foreign-key definition by hiding explicit delete and update rules. The database still enforces the constraint, and no data loss was observed.
• Steps to Reproduce:
  1. Create a parent table and two child tables in the local Doltgres database.
  2. Add one foreign key without ON DELETE or ON UPDATE clauses, and add the other with ON DELETE RESTRICT and ON UPDATE RESTRICT.
  3. Query each constraint with pg_get_constraintdef and compare the definitions.
  4. Observe that both definitions omit the explicit RESTRICT actions, even though both constraints reject parent-row changes.
• Stub / mock content: The test used local parent and child tables in a local Doltgres PostgreSQL-wire database; no application stubs, mocks, or route bypasses were used.
• Code Analysis: The runtime SQL evidence creates fk_omit_3 without actions and fk_restrict_3 with ON DELETE RESTRICT ON UPDATE RESTRICT; pg_get_constraintdef returns the same bare FOREIGN KEY ... REFERENCES ... text for both. The production implementation in server/functions/pg_get_constraintdef.go, getConstraintDef, formats every foreign key at lines 86-90 and never reads fk.Item.OnDelete or fk.Item.OnUpdate, so it cannot emit RESTRICT, CASCADE, SET NULL, or SET DEFAULT for any foreign key. The underlying action data is available: server/ast/foreign_key_constraint_table_def.go maps tree.Restrict to vitess.Restrict at lines 53-60, and server/tables/pgcatalog/pg_constraint.go maps Restrict to the PostgreSQL catalog code 'r' at lines 88-95. The smallest fix is to append the appropriate ON DELETE and ON UPDATE clauses in getConstraintDef based on fk.Item.OnDelete and fk.Item.OnUpdate, omitting only NoAction as PostgreSQL does for an implicit default. This defect is not introduced by the PR: the PR changes testing/go/enginetest/query_converter_test.go lines 1548-1551 to map omitted parser actions to tree.NoAction and updates the expected SQL, but it does not change server/functions/pg_get_constraintdef.go or the catalog reporting path.

Evidence Package

• text/FOREIGN-3/FOREIGN-3-constraint-definition.txt — 3 KB

Tip

Reply with @itoqa to send us feedback on this test run.

[github-actions]

	Main	PR
Total	42090	42090
Successful	18918	18918
Failures	23172	23172
Partial Successes1	5325	5325

	Main	PR
Successful	44.9465%	44.9465%
Failures	55.0535%	55.0535%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩