Skip to content

fix: order SQL functions after relation creation - #281

Open
dilame wants to merge 1 commit into
stripe:mainfrom
dilame:fix/sql-function-relation-deps
Open

dilame wants to merge 1 commit into
stripe:mainfrom
dilame:fix/sql-function-relation-deps

Conversation

@dilame

@dilame dilame commented May 13, 2026

Copy link
Copy Markdown

Summary

  • order SQL-language function create/replace vertices after target-schema tables and sequences
  • add an acceptance regression for a SQL function whose body inserts into a table created in the same migration

Why

PostgreSQL validates SQL function bodies at CREATE FUNCTION time and errors if referenced relations do not exist, but it does not persist those body relation references as pg_proc to pg_class rows in pg_depend. This makes exact relation dependencies unavailable to the planner; the fix mirrors the existing broad procedure relation ordering, scoped only to SQL functions to avoid PL/pgSQL trigger cycles.

Test

PATH="/Applications/Postgres.app/Contents/Versions/17/bin:$PATH" go test ./pkg/diff -count=1
PATH="/Applications/Postgres.app/Contents/Versions/17/bin:$PATH" go test ./internal/migration_acceptance_tests -count=1

iambilotta added a commit to cocreiamo/pg-schema-diff that referenced this pull request Sep 10, 2026
…s not rely on function ordering

A policy created with a brand-new table strips its hazards whether it is inlined or
deferred to its own vertex, so the subquery case expects none. The cycle-shaped case
uses a plpgsql function: a sql function reading a table created in the same plan is not
ordered after it on main (see stripe#281 and stripe#286), and that is not what the case is about.
Also gofmt.
iambilotta added a commit to cocreiamo/pg-schema-diff that referenced this pull request Sep 10, 2026
…s not rely on function ordering

A policy created with a brand-new table strips its hazards whether it is inlined or
deferred to its own vertex, so the subquery case expects none. The cycle-shaped case
uses a plpgsql function: a sql function reading a table created in the same plan is not
ordered after it on main (see stripe#281 and stripe#286), and that is not what the case is about.
Also gofmt.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant