Repository navigation
fix: create SQL functions after the later-batch functions they call (#596) - #616
Conversation
|
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Cross-batch scheduling and imprecise call detection can still emit functions after objects that require them.
Get a fresh assessment by requesting another Copilot review.
Review effort: Balanced
Findings: 3
Open (3)
What changed in this PR
Improves PostgreSQL function creation ordering when SQL functions call functions deferred to later dependency batches.
Changes:
- Extracts transitive caller deferral into
holdBackCallers. - Applies caller deferral across table and view batches.
- Extends dependency regression fixtures and expected plans.
| File | Description |
|---|---|
| testdata/diff/dependency/issue_530_function_table_function_chain/plan.txt | Updates human-readable expected plan. |
| testdata/diff/dependency/issue_530_function_table_function_chain/plan.sql | Updates expected plan SQL. |
| testdata/diff/dependency/issue_530_function_table_function_chain/plan.json | Updates expected JSON plan. |
| testdata/diff/dependency/issue_530_function_table_function_chain/new.sql | Adds an indirect SQL-function dependency case. |
| testdata/diff/dependency/issue_530_function_table_function_chain/diff.sql | Updates expected migration SQL. |
| internal/diff/diff.go | Adds transitive caller deferral across creation batches. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…596) New functions are emitted in several batches (before/after function-dependent tables, after views, after aggregates), and topologicallySortFunctions only orders within a batch. A LANGUAGE sql function that touches no new table but calls a function deferred to a later batch was created first, and apply failed with `function ... does not exist` because SQL bodies are validated at creation. Generalize the transitive hold-back already used for aggregate callers into holdBackCallers and apply it to the table and view batches. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
e57436c to
ccc263c
Compare
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>


Summary
Follow-up to #615 (merged), found while applying the schema attached to #596. Since #615 the schema plans, but
pgschema applythen failed:New functions are emitted in several batches (before function-dependent tables, after them, after the last table batch, after views, after aggregates).
topologicallySortFunctionsorders functions only within a batch. ALANGUAGE sqlfunction that touches no new table itself but calls a function deferred to a later batch stayed in the first batch, so it was created before its callee — and SQL-language bodies are validated at creation time.Fix: the transitive "a caller of a held-back function waits too" closure that
splitFunctionsCallingAggregatesalready had is extracted intoholdBackCallersand also applied to the table batches and the view batch. Only SQL-language functions move; plpgsql resolves calls at run time, and moving those could push trigger functions past their triggers.Fixes #596
Test plan
testdata/diff/dependency/issue_530_function_table_function_chain:first_is_flagged()references no table but callsx_is_flagged, which is created after tablex. Fails before the fix at apply, passes after.dependency/,create_function/,create_aggregate/for bothTestDiffFromFilesandTestPlanAndApply.pgschema applyand re-plans toNo changes detected.🤖 Generated with Claude Code