docs(ci): clarify Postgres support

[NikolayS]

What changed

• restore the README support badge and roadmap to stable PostgreSQL 14–18;
• explicitly describe PostgreSQL 19 beta as a continuously tested forward-compatibility lane, not a production-support claim;
• align upgrade-matrix comments and contributor rules with that distinction;
• keep all PostgreSQL 19 beta CI coverage unchanged.

Fixes #324.

Why

The repository tests postgres:19beta1, but the badge shortened that to PostgreSQL 19 support. Beta compatibility is valuable evidence, but it is not the same commitment as support for a final production major.

Validation

• parsed .github/workflows/ci.yml with Ruby YAML;
• confirmed stale 14–19 support strings are gone from the changed support surfaces;
• git diff --check.

This is intentionally a draft and has not been merged.

[NikolayS]

REV rubric review

This is a manual execution of the repository's five applicable REV rubrics because the automated ultrareview quota was unavailable. It is not bot output. SOC2 was omitted as required.

• Bug hunter: the stable 14–18 support statement and separate 19 beta compatibility lane match the CI matrix.
• Security reviewer: no security-sensitive behavior changes.
• Test analyzer: YAML parsing and support-string checks are adequate for the prose/config delta.
• Docs reviewer: the production-support distinction is clear and uses the repository's preferred Postgres terminology.
• Guidelines checker: CI is 17/17 green and commits are within the repo-specific type/length rules.

Blocking findings: none in the patch.

Nonblocking: the PR title uses Postgres while the main commit subject uses PostgreSQL; the generic commit standard asks titles to match the main subject. Lifecycle still requires a real-user evidence comment before merge. This COMMENT review is not an approval.

[NikolayS]

Real-user verification evidence

Verified exact head 8ab07d118b5c6340ca0843fd672ce14cac8a31d2
against a fresh Postgres 18 database using the stable README path.

Commands used:

export PAGER=cat
psql --no-psqlrc \
  --set=ON_ERROR_STOP=1 \
  --dbname="$PGQUE_TEST_DSN" \
  --file=sql/pgque.sql

psql --no-psqlrc \
  --set=ON_ERROR_STOP=1 \
  --dbname="$PGQUE_TEST_DSN"

In the second command I executed the README sequence verbatim: create the
queue, register the consumer, send, force the next tick, run the ticker,
receive, and acknowledge the batch.

Key output:

installed version: 0.2.0
send/tick/receive/ack round trip: passed

The supported Postgres wording, badge, matrix, and roadmap statements were
also checked together. All 17 CI checks are green on this exact head.

[NikolayS]

samorev Code Review Report

• PR: docs(ci): clarify Postgres support #329 - docs(ci): clarify Postgres support
• Author: @NikolayS
• AI-Assisted: Yes

Pipeline	Coverage
unknown	Not reported

---

REVIEW FINDINGS (7)

HIGH MR/PR state - Review target is draft

The review target is still marked as draft.
Fix: Mark it ready for review before merge.

CRITICAL CI/Pipeline - Pipeline status is unknown

Provider CI reported status unknown.
Fix: Fix failing checks and rerun review.

MEDIUM [docs] Roadmap table row switched from the table's ✅ convention to the bare word "Yes", making a completed item render as inconsistent with — and visually weaker than — every other row in the same "Done" column.

| Modern Postgres support (14–18; 19 beta tested) | Yes | while all neighbouring rows keep | PgQ core engine | ✅ |, | Pure SQL / PL/pgSQL install | ✅ |, | Managed Postgres support | ✅ |
Fix: Restore ✅ for the Done cell and keep the scoping in the feature cell: | Modern Postgres support (14–18; 19 beta tested) | ✅ |. If the intent was to signal partial status, use a distinct marker consistently across the table rather than one row in prose.

MEDIUM [tests] Reclassifying PG19 as an unsupported beta lane leaves the upgrade job with no coverage of the newest supported major. The matrix endpoints are 14 and 19beta1, so under the new definition the upgrade path is exercised on the oldest supported version and on a version the project explicitly does not support — PG15–18 upgrades are untested, including the newest production major users are told to run.

pg_version: ['19beta1', '14'] under the comment # Upgrade coverage uses the oldest supported PG endpoint and the # newest beta forward-compatibility lane.
Fix: Add '18' to the upgrade matrix so the newest supported major has upgrade coverage, keeping '19beta1' as the extra forward-compat lane: pg_version: ['19beta1', '18', '14']. If cost is a concern, at minimum swap in '18' and run the beta upgrade lane on a schedule.

MEDIUM [docs] The support-claim correction is only applied to three files, and the PR description scopes its own verification to "the changed support surfaces". Support ranges in this kind of project typically also appear in docs pages, SPEC, the devel/sql/ README, contributor docs, and release/packaging metadata; any of those still saying 14–19 reintroduces exactly the overclaim this PR fixes.

PR description: "confirmed stale 14–19 support strings are gone from the changed support surfaces" — changed files limited to .github/workflows/ci.yml, CLAUDE.md, README.md
Fix: Run a repo-wide sweep (e.g. grep -rniE '14[-–]19|PostgreSQL[ -]19 support|PG ?19 support') across docs, SPEC.md, devel/, and packaging metadata, and update or explicitly confirm each hit before merge.

LOW [guidelines] The new CLAUDE.md sentence makes the beta lane optional ("may be added") while the PR's stated intent is that the PG19 beta CI coverage stays in place. As written, a contributor could delete the 19beta1 jobs without violating rule 5, since the mandatory list is only 14–18.

5. **Test against PG 14, 15, 16, 17, 18.** CI must cover all supported versions. + A development/beta Postgres lane may be added for forward compatibility; it does not expand the supported production matrix before the final major.
Fix: State the actual policy: CI must cover 14–18 and must keep a beta lane for the next major while one exists; the beta lane does not expand the supported production matrix. E.g. "…and must keep a lane for the in-development major (currently 19 beta); that lane is forward-compatibility evidence only."

LOW [guidelines] The docs now say beta coverage "is not a production-support claim", but the beta job remains an ordinary blocking matrix leg. Upstream beta churn (a 19beta2 image, a behaviour change) will turn the required check red and block unrelated merges on a lane the project explicitly does not support.

pg_version: ['19beta1', '14'] with only fail-fast: false; no continue-on-error or non-required marking for the beta leg
Fix: Either mark the beta leg non-blocking (continue-on-error: ${{ startsWith(matrix.pg_version, '19beta') }}) or exclude it from required status checks, so the "tested, not supported" framing matches the merge gate. If blocking is deliberate, say so in the workflow comment.

---

Summary

Area	Findings	Potential	Filtered
CI/Pipeline	1	0	0
Security	0	0	0
Bugs	0	0	0
Tests	0	1	0
Guidelines	0	2	0
Docs	1	1	0
Metadata	1	0	0

Note:

• Findings: High-confidence issues (8-10/10) - blocking or non-blocking per severity
• Potential: Medium-confidence issues (4-7/10) - review manually
• Filtered: Low-confidence issues (0-3/10) - excluded as likely false positives

Review metadata

provider=github
kind=pr
project=NikolayS/PgQue
number=329
target=github:NikolayS/PgQue#329
state=OPEN
draft=true
diff_lines=60
diff_added=8
diff_removed=5
diff_bytes=4558
comments_count=1
commits_count=3
ci_status=unknown
ci_summary=total=18 success=17 failure=0 pending=0 other=1
prompt=.claude/commands/review-mr.md
blocking=false
posted_by=gh
no_comment=false
live_posting=posted

---

samorev-assisted review (AI analysis by Tanya301/samorev)