Conversation
A function or procedure whose signature names a relation's row type — an argument type, the RETURNS type, or a RETURNS TABLE column — is validated by PostgreSQL at CREATE time, so that relation must exist first and must be dropped after. Track those dependencies per relation kind (table, view, materialized view) from pg_depend and add the matching ordering edges. This replaces the unsafe alternative of ordering a routine after every table: that closes a cycle whenever a domain's CHECK calls the routine while a table column is typed with the domain (routine -> table -> domain -> routine). Only the relations the signature actually references are ordered.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Adds tracking and ordering for the relations whose row type a function or procedure names in its signature.
GetDependsOnRelationsquery reads, frompg_depend, the relations (relkindinr,p,v,m) whose row type appears in a routine's signature — an argument type, theRETURNStype, or aRETURNS TABLEcolumn — including references through the row type's array type.FunctionandProceduregainDependsOnRelations;RelationDependencycarries therelkindso the edge can target the generator that owns the relation.DROPbefore theirs. Views and materialized views are covered too — the procedure generator's blanket "after every table" ordering never covered them.Why
PostgreSQL resolves a routine's argument and return types at
CREATEtime, so a relation named there must already exist. That relation's row type is apg_typeentry, but it is not a standalone composite type, so no existing dependency query saw it. A plan that created such a routine before the relation failed plan validation withtype <schema>.<relation> does not exist.The tempting alternative — ordering every routine after every table, the best-effort approach the procedure generator already takes — is unsafe: it closes a cycle whenever a domain's
CHECKcalls the routine while a table column is typed with that domain (routine → table → domain → routine). Only the relations a signature actually references are ordered.Validation
go test ./...New acceptance cases cover a table row type as a function argument, as a
RETURNS TABLEcolumn, a view row type as an argument (function and procedure), and the matchingDROPorder, each asserting the exact statement order.The domain
CHECKregression case for the cycle above cannot live in this branch — it needs domains. It lives in the fork's integration branch alongside#306as glue, the same wayCOMMENT ON DOMAINdoes.