Remove redundant client_min_messages handling from install script

[jnasbyupgrade]

CREATE EXTENSION already raises client_min_messages to WARNING for the install script (only-raising, so a stricter caller is respected) and restores it afterward — so the script's own setting was redundant, and being blind it actually lowered a stricter caller's level during install. Remove it. (Also drops the old save/restore into a temp table.)

Closes #2

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 8f0fcdc1-c863-4a8f-945c-d22fdb1926d1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[jnasbyupgrade]

@claude please review this PR.

[claude]

Claude finished @jnasbyupgrade's task in 5m 54s —— View job

---

Review of PR #3 — Don't clobber caller's client_min_messages on install

• Gather context (diff, CLAUDE.md, repo conventions, CI history)
• Understand the request
• Review code changes
• Post review feedback

Summary

The change replaces the old "capture into a temp table, restore only on success" approach with a DO $$ ... $$ block that stores the caller's original client_min_messages in a transaction-local custom GUC (extension_drop.client_min_messages), conditionally raises to WARNING only if the caller's setting is more verbose, and restores it explicitly at the end of the script. Overall this is a solid, well-commented fix — the severity-ordering logic (c_levels array, including the documented LOG quirk between DEBUG1 and NOTICE for this specific GUC) is correct, and the transaction-scoping reasoning (plain SET rolls back automatically on failure; set_config(..., true) for transaction-local storage of the original value) checks out.

Findings

1. Possible version-compatibility regression: pg_catalog.array_position() requires PostgreSQL ≥ 9.5. (sql/extension_drop--1.0.0.sql:30-31, sql/extension_drop.sql:29-30)
   META.json's build prereqs declare "PostgreSQL": "9.3.0", and .github/workflows/ci.yml explicitly tests down to 9.3/9.4. array_position/array_positions were added in PostgreSQL 9.5, so this DO block would fail with function pg_catalog.array_position(text[], text) does not exist on 9.3/9.4 if the project still intends to support those versions.
   Note: I checked the latest CI run (https://github.com/Postgres-Extensions/extension_tools/actions/runs/29278703111) and the regression tests are currently failing with "exit code 3" across every PG version in the matrix (9.3 through 17), with the Makefile configured to ignore that failure (Error 1 (ignored)) — so this is a pre-existing, unrelated test-harness issue, and CI would not currently catch a real array_position incompatibility either way.
   If 9.3/9.4 support still matters, consider replacing the array_position lookups with a CASE/position()-based mapping that doesn't require 9.5+.
   Fix this →

2. No regression test added for the bug being fixed. (test/deps.sql, test/sql/*)
   None of the existing tests set client_min_messages to something stricter than WARNING (e.g. WARNING/ERROR) before CREATE EXTENSION extension_drop and assert it's preserved afterward — which is exactly the scenario this PR fixes (issue Install script blindly sets client_min_messages, overriding the caller's setting #2). Worth adding a small test asserting current_setting('client_min_messages') is unchanged after install/drop when starting from a non-default level.

3. Minor/no action needed: sql/extension_drop--1.0.0.sql is marked DO NOT EDIT - AUTO-GENERATED FILE, but this PR hand-edits it in lockstep with sql/extension_drop.sql. Both files were kept identical, matching this repo's existing convention (this predates the PR), so no issue — just noting it's intentional and correctly done.

Nothing else stood out; the NULL-safe fallback behavior when a level isn't in c_levels (e.g. FATAL/PANIC) defaults to not raising, which is actually the safe/correct outcome.