Document superuser/trusted; split general PostgreSQL guidance into its own docs - #113
Open
jnasbyupgrade wants to merge 1 commit into
Open
Conversation
… into its own docs Neither README.asc nor CLAUDE.md said anything about the `.control` file parameters that decide who may run `CREATE EXTENSION`. Both are now covered, but in new files rather than in the existing docs: this material is about PostgreSQL itself, not about pgxntool, and mixing the two makes it unclear which claims pgxntool is actually responsible for. - `POSTGRES-NOTES.asc` (human-facing): `superuser = false` drops the superuser requirement and runs the script as the caller, who must already hold every privilege it needs; `trusted = true` lets a non-superuser with CREATE on the database install it but runs the script as the bootstrap superuser, is only consulted when `superuser` is true, and needs PG13+. Carries the security warning and links PostgreSQL's own security-considerations section. - `CLAUDE-POSTGRES.md` (agent-facing): agents reach for `trusted = true` as the quick answer to "let a non-superuser install this" and present it bare, which reads as a recommendation for what is actually a privilege-escalation surface. Rule: `trusted` may never be mentioned without also offering `superuser = false` and stating the security consequences. One-directional -- `superuser = false` on its own is fine. `README.asc` and `CLAUDE.md` each gain a pointer to their counterpart; CLAUDE.md also uses an `@` import so the rules load automatically where that is supported. The "never produce metrics or estimates without data" rule moves to CLAUDE-POSTGRES.md, where it belongs -- it has nothing to do with pgxntool and was orphaned under "Related Repositories". Both new files are already covered by `.gitattributes` (`*.asc`, `*.md` are export-ignored), so they reach subtree consumers but not PGXN distributions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
Neither
README.ascnorCLAUDE.mdmentioned the.controlfile parameters that decide who may runCREATE EXTENSION. This adds that, but in new files rather than in the existing docs — the material is about PostgreSQL itself, not about pgxntool, and mixing the two blurs which claims pgxntool is actually responsible for.New files
POSTGRES-NOTES.asc(human-facing) — short section on who can install an extension:superuser = falsedrops the superuser requirement outright; the install/update script then runs as the caller, who must already hold every privilege it needs — nothing is granted implicitly.trusted = truelets any non-superuser withCREATEon the database install it, but runs the script as the bootstrap superuser. Only consulted whensuperuseris true; PG13+.superuser = falseis usually the better of the two when the extension doesn't need superuser-only capabilities.CLAUDE-POSTGRES.md(agent-facing) — the rule this PR was actually requested for:One-directional: mentioning
superuser = falsealone is fine. The rationale is spelled out —trusted = trueis the fastest-to-mind answer to "how do I let a non-superuser install this?", so raising it bare reads as a recommendation for what is really a privilege-escalation surface.Wiring
README.ascgains a== General PostgreSQL Notessection pointing atPOSTGRES-NOTES.asc.CLAUDE.mdgains a scope sentence plus a## Read CLAUDE-POSTGRES.mdsection with an@CLAUDE-POSTGRES.mdimport, so the rules load automatically where that's supported and are still findable where it isn't.CLAUDE.md's Related Repositories list intoCLAUDE-POSTGRES.md. It is purely general agent guidance with no connection to pgxntool, and it was sitting under a heading it had nothing to do with..gitattributesneeds no change:*.ascand*.mdare alreadyexport-ignore, so both new files reach subtree consumers but not PGXN distributions.Notes for review
README.htmlwas not regenerated. It is already twoREADME.asccommits stale on master, so regenerating here would fold unrelated drift into this diff. Worth handling separately.README.asc/CLAUDE.md(extension versioning discipline, pg_regress mechanics, pg_tle background, the pgTAP recommendation, the GNU Makewildcardcaching quirk). None of it moved here — that would make this diff unreviewable. Listed in the PR discussion for a follow-up decision.🤖 Generated with Claude Code