refactor: rename to XXX; clarify log vs task queue

[NikolayS]

Why

From the HN thread on the prior PgQue release:

"Why insist on calling this a queue when it doesn't really have queue semantics? Queues do the job of load balancing between different workers. When workers acknowledge tasks, they get deleted, and there are visibility timeouts. This is a log."
— adhocmobility on HN

The commenter is right. What ships is an append-only event log with per-consumer cursors and native fan-out — a Kafka topic shape, not an ActiveMQ / RabbitMQ / SQS task-queue shape. The old name was sending the wrong mental model at first read.

New name: logres. Short, no pg_ prefix (avoids extension confusion), zero collision with Postgres built-ins, evokes log directly.

(Supersedes #74, which proposed pg_current and got tangled with Postgres built-ins like pg_current_xact_id, pg_current_snapshot, pg_current_logfile, etc.)

Rename

Project identifier pgque / PgQue → logres everywhere (92 files, mechanical):

• Schema: every pgque.* in SQL → logres.*.
• Roles: pgque_reader / pgque_writer / pgque_admin → logres_reader / logres_writer / logres_admin.
• Install file: sql/pgque.sql → sql/logres.sql (4770 lines rebuilt via build/transform.sh).
• Source tree: sql/pgque-api/ → sql/logres-api/; sql/pgque-additions/ → sql/logres-additions/.
• Tests: test_pgque_* → test_logres_*; every pgque.* call renamed.
• Build system: build/transform.sh now rewrites pgq → logres instead of pgq → pgque.
• Client libraries: clients/python/pgque/ → clients/python/logres/; clients/go/pgque.go → clients/go/logres.go; package names, module paths, imports renamed across Python / Go / TypeScript.
• CI: .github/workflows/ci.yml test DB name and credential env renamed.
• Docs: every pgque / PgQue in README.md, docs/*.md, blueprints/*.md, CLAUDE.md, NOTICE renamed.

Preserved intentionally: pgq (parent project), pgqd (parent's daemon), PgQ (prose), pgq/ submodule, and the one build/transform.sh comment that names pgqueue as a boundary-case identifier to avoid mangling.

Client / schema compatibility: old pgque clients break against new logres schema and vice versa. Users upgrading need both sides.

README clarifications

H1 + tagline

• H1 → "logres — event log for Postgres"
• Tagline → "Zero-bloat event log, PgQ heritage. One SQL file to install, pg_cron to tick." (dropped the "queue" noun)

§Comparison subsection

"When to use logres vs. a job queue" replaced with "Log, not task queue (but can serve task-queue workloads)":

• Good fit for log-as-task-queue: per-key ordered processing (partition by key), high-throughput uniform tasks, replayable pipelines, multi-consumer event streams, event-sourced systems where "task" and "event" collapse into one primitive.
• Bad fit: high-variance task duration (head-of-line blocking), per-message retry with backoff and priority, SQS-style visibility timeouts, dynamic load balancing across heterogeneous workers.
• For bad-fit: River / graphile-worker / Oban / pgmq / RabbitMQ / ActiveMQ / SQS.

The first-screen self-qualification line ("closer to Kafka (log) than to ActiveMQ or RabbitMQ (task message queue)") stays — that's the one-sentence version of the same distinction.

Out of scope

• GitHub repo rename NikolayS/pgque → NikolayS/logres is owner action. Existing URLs redirect for 1 year after.
• Schema-migration helper — pre-v0.1; clean reinstall acceptable. MIGRATION.md can land if/when a published pgque v0.1 exists in the wild.

Test plan

• build/transform.sh assembles sql/logres.sql cleanly; all checks pass.
• No pgque / PgQue strings remain (except the boundary-case comment in transform.sh).
• CI on PG 14–18: test DB name logres_test + every logres.* call in every test.
• Acceptance suite (tests/acceptance/) runs green.
• Client smoke tests after their imports pick up renamed modules.

🤖 Generated with Claude Code