@yawlabs/postgres-mcp 0.6.5 → 0.6.10

package/CHANGELOG.md

@@ -7,6 +7,77 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.6.10] - 2026-05-16
+
+### Infrastructure
+- Republishes the 0.6.7-0.6.9 coverage additions, which never reached
+  npm. The `pg_top_queries orderBy=calls` numeric-vs-lexical ordering
+  test was removed after three round-trips trying to make it
+  environment-independent. pg_stat_statements on PG17/18 fingerprints
+  `SELECT 1 AS x_a` and `SELECT 2 AS x_b` to the same query id (column
+  aliases drop out of the jumble even though they're preserved in the
+  displayed text), so two markers with different aliases collapse to
+  one entry and the ordering assertion has nothing to compare. Local
+  WSL clusters differentiate; CI doesn't. The alias-shadowing trap at
+  `stats.ts:60-67` remains documented at the call site and the other
+  six coverage additions are unaffected.
+
+## [0.6.9] - 2026-05-16 [UNPUBLISHED]
+
+Tagged but never published to npm -- the pg_top_queries ordering test
+still failed in CI even after switching marker queries from cursor-
+wrapped handler calls to raw `runInternal`. Root cause was column-alias
+jumbling in pg_stat_statements; the test was removed in 0.6.10.
+
+## [0.6.8] - 2026-05-16 [UNPUBLISHED]
+
+Tagged but never published to npm -- the v0.6.8 attempt at the
+pg_top_queries test still depended on `pg_stat_statements.track_utility`
+being on, which the CI image's defaults don't guarantee. Shipped in 0.6.9.
+
+## [0.6.7] - 2026-05-16 [UNPUBLISHED]
+
+Tagged but never published to npm -- the initial coverage additions
+included an ordering test for pg_top_queries that failed in CI on a
+test-stability issue (not a code issue). The other six coverage
+additions shipped in 0.6.10.
+
+
+
+### Infrastructure
+- Closed seven coverage gaps surfaced by a coverage audit. No behavior
+  changes; each test pins a branch the existing suite exercised on only
+  one side, or a structural property a regression could silently violate:
+  - `pg_inspect_locks` real ACCESS EXCLUSIVE contention with two side
+    clients. Covers the LATERAL `unnest(pg_blocking_pids(...))` and the
+    per-(blocked, blocker) row shape the v0.6.6 description claims.
+  - `pg_top_queries` `orderBy: 'calls'` numeric (not lexical) ordering.
+    A 12-call query must rank above a 2-call query -- pins the
+    alias-shadowing fix where unqualified `calls` would resolve to the
+    text output alias and sort lexically (`"2" > "12"`).
+  - `pg_table_bloat` `minDeadRatio` threshold filter, as a relative
+    property (filtered rows are at or above the threshold; baseline rows
+    below the threshold are absent from filtered). Order-independent.
+  - `pg_table_bloat` with-schema filter -- no cross-schema leakage when
+    scoped.
+  - `pg_seq_scan_tables` and `pg_unused_indexes` no-schema branch --
+    spans user schemas and excludes `pg_*` / `information_schema`.
+  - `pg_describe_table` on a materialized view -- `kind='materialized_view'`
+    branch of the relkind CASE.
+
+## [0.6.6] - 2026-05-16
+
+### Docs
+- `pg_table_privileges` description now flags the visibility caveat:
+  `information_schema.table_privileges` is filtered by what the calling role
+  can see, so a least-privileged role may miss grants involving unrelated
+  third-party roles. Recommends superuser or `pg_read_all_data` for a
+  complete picture.
+- `pg_inspect_locks` description now documents the row shape: one row per
+  (blocked_pid, blocking_pid) pair, so a session waiting on multiple
+  blockers appears on multiple rows. Suggests grouping by `blocked_pid`
+  for a per-blocked-session count.
+
 ## [0.6.5] - 2026-05-15
 
 ### Fixed

package/dist/index.js

@@ -36361,7 +36361,7 @@ var identSchema = external_exports.string().min(1).max(63).refine((v) => Buffer.
 var adminTools = [
   {
     name: "pg_inspect_locks",
-    description: "Show current lock contention: which sessions are blocked and who is blocking them. Returns blocked PID, blocking PID, lock types, relation being contested, and the queries involved. Use this first when a tool call hangs or the app feels stuck - it's the fastest way to identify a long-held transaction holding a lock.",
+    description: "Show current lock contention: which sessions are blocked and who is blocking them. Returns blocked PID, blocking PID, lock types, relation being contested, and the queries involved. Use this first when a tool call hangs or the app feels stuck - it's the fastest way to identify a long-held transaction holding a lock. Row shape: one row per (blocked_pid, blocking_pid) pair. A session waiting on multiple blockers appears on multiple rows -- group/deduplicate by `blocked_pid` if you want a per-blocked-session count.",
     annotations: {
       title: "Inspect blocking locks",
       readOnlyHint: true,
@@ -36447,7 +36447,7 @@ var adminTools = [
   },
   {
     name: "pg_table_privileges",
-    description: "Show which roles have which privileges (SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER) on a table or on every table in a schema. If `table` is omitted, the result spans every table in `schema`, ordered by table then grantee. Use this to answer 'who can write to this table?' or to audit schema-wide access before a migration.",
+    description: "Show which roles have which privileges (SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER) on a table or on every table in a schema. If `table` is omitted, the result spans every table in `schema`, ordered by table then grantee. Use this to answer 'who can write to this table?' or to audit schema-wide access before a migration. Visibility caveat: backed by `information_schema.table_privileges`, which postgres filters by what the calling role can see. A least-privileged role may not see grants involving unrelated third-party roles. For a complete picture, run as a superuser or a member of `pg_read_all_data`.",
     annotations: {
       title: "Show table privileges",
       readOnlyHint: true,
@@ -37550,7 +37550,7 @@ function compareVersions(a, b) {
 }
 
 // src/index.ts
-var version2 = true ? "0.6.5" : (await null).createRequire(import.meta.url)("../package.json").version;
+var version2 = true ? "0.6.10" : (await null).createRequire(import.meta.url)("../package.json").version;
 var subcommand = process.argv[2];
 if (subcommand === "version" || subcommand === "--version") {
   console.log(version2);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yawlabs/postgres-mcp",
-  "version": "0.6.5",
+  "version": "0.6.10",
   "mcpName": "io.github.YawLabs/postgres-mcp",
   "description": "PostgreSQL MCP server - query, schema introspection, explain, and health checks for AI assistants",
   "license": "MIT",