Add extension_requires() and extension_requires_are() - #372
Add extension_requires() and extension_requires_are()#372jnasbyupgrade wants to merge 6 commits into
Conversation
Proposed API for verifying an extension's declared dependencies, pulled from pg_extension/pg_depend (not pg_available_extensions). Both guard on the target extension not being installed the same way has_extension() does. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@theory any comments on the proposed API before I finish this? There's also 2 more fields from There's also One other interesting bit... Claude originally mentioned in the docs that the new functions only look at |
4a1b678 to
4bfad39
Compare
Adds doc/pgtap.mmd entries mirroring has_extension()/extensions_are() so the proposed API is easy to review alongside the SQL. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4bfad39 to
458e439
Compare
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Existing extension docs don't characterize control file vs. runtime state, so drop that contrast here too and just describe what the function checks. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…re() doc Not verified against a real test run; will replace with output copied from test/expected/extension.out once that coverage exists. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Any chance you can provide an LLM-free PR? |
theory
left a comment
theory
left a comment
There was a problem hiding this comment.
Will need an upgrade script and patch. Function names seem fine.
| # citext | ||
| # isn | ||
|
|
||
| ### `extension_requires_are()` ### |
There was a problem hiding this comment.
I suggest dropping _are(). Oh, you have that for checking a single requirement. Fine I guess, if semantically clumsy.
| recorded by PostgreSQL when `:extension` was created. If `:extension` | ||
| itself does not exist, the test fails the same way `has_extension()` does. | ||
| If the test description is omitted, it will be set to "Extension | ||
| `:extension` should require extension `:required_extension`". Example: |
There was a problem hiding this comment.
We don't use backticks for names. Follow existing patterns.
| IF NOT _ext_exists($1) THEN | ||
| RETURN fail($3) || E'\n' || diag( | ||
| ' Extension ' || quote_ident($1) || ' does not exist' | ||
| ); | ||
| END IF; | ||
|
|
||
| RETURN _are( | ||
| 'required extensions', | ||
| ARRAY( SELECT _extension_requires($1) EXCEPT SELECT unnest($2) ), | ||
| ARRAY( SELECT unnest($2) EXCEPT SELECT _extension_requires($1) ), | ||
| $3 | ||
| ); |
There was a problem hiding this comment.
Can we have a single query execution instead of multiple? Have _extension_requires() return NULL instead of an empty array if the extension doesn't exist.
2 participants
Proposes two new assertion functions for verifying an extension's declared dependencies (its control file
requires), analogous to the existinghas_extension()/extensions_are()pair:extension_requires( extension, required_extension[, description] )— asserts thatextensionrequiresrequired_extension.extension_requires_are( extension, requires[][, description] )— asserts the exact set of extensions thatextensionrequires, with Extra/Missing diagnostics likeextensions_are().Both are backed by a new internal helper,
_extension_requires(name), which reads the requirement frompg_depend/pg_extension(the runtime record of what actually got pulled in viaCREATE EXTENSION ... REQUIRES), notpg_available_extensions. Both guard on the target extension not being installed, failing the same wayhas_extension()does rather than reporting a confusing all-missing diff.Test plan
Manually verified against
earthdistance(which requirescube):extension_requires('earthdistance', 'cube')passesextension_requires('earthdistance', 'citext')failsextension_requires_are('earthdistance', ARRAY['cube'])passesextension_requires_are('earthdistance', ARRAY['citext'])fails with Extra/Missing diagnosticshas_extension()when the base extension doesn't exist