Distribution & discoverability: how do users find pgque?

[NikolayS]

Background

PgQue's default install is \i sql/pgque.sql — there's no .control file on disk, so the standard PG extension crawlers (PGXN, pgxman, etc.) can't index it. Even our optional pg_tle install (sql/pgque-tle.sql) is invisible to them — TLEs only exist after pgtle.install_extension() runs, with the body stored in pg_tle's catalog table. PGXN itself has been mostly dormant for years and has no TLE-aware data model anyway, so it's not the right bet here.

This issue is a thinking-out-loud space for distribution / discoverability. Not 0.2.0 priority — defer until we have something to ship.

Current discoverability surface

• GitHub repo + README only
• HN discussion thread (one-shot)
• No registry presence

Live registries that could matter

• database.dev (dbdev, by Supabase) — the closest thing to a TLE registry. Supports dbdev publish of a TLE bundle; users select dbdev.install('owner-pgque'). Closest fit for our pg_tle install path.
• Trunk / pgt.dev (Tembo) — newer, mostly C extensions but they've added TLE entries. Manual submission.
• pgxman — apt-style C-extension packaging; no TLE story today.
• AWS RDS extension catalog — AWS-curated only.

Lowest-effort wins

1. Add GitHub topics (postgres, postgres-extension, pg-tle, tle, trusted-language-extensions, queue) so we show up in GitHub facet search and awesome-* lists.
2. Manual submission to awesome-postgres and the postgresql.org/community/projects list.
3. Publish a TLE bundle to dbdev so the only TLE-aware crawler can find us.

Open questions

• Does dbdev publish accept the verbatim contents of our sql/pgque-tle.sql body, or do we need a separate manifest format? (Spec: https://supabase.github.io/dbdev/)
• Do we want a META.json-style manifest at the repo root anyway, even if no current crawler consumes it? Useful for future PGXN-v2 / Trunk indexing without re-architecting.
• Tagging strategy: do we tag v0.2.0 releases on GitHub so registries that look at GitHub Releases can pick them up?
• Versioning across registries: pgque.version() returns 0.2.0-dev today; the dbdev / trunk publish flow expects stamped semver. Once we cut a real 0.2.0, registries can index that.
• Is it worth a tiny landing site (e.g. pgque.dev) for SEO / first-touch discoverability, or is the GitHub README enough for v0.2?

Out of scope for this issue

• The actual implementation of any of the above. This issue is just for surfacing the question and capturing options before we commit to a direction.

Related: client library distribution is split into separate issues (Python / Go / TypeScript) and is 0.2.0 priority — see those for the per-ecosystem story.

[NikolayS]

Quick progress update:

• Added GitHub topics for the lowest-effort discoverability win: postgres, postgresql, postgres-extension, pg-tle, tle, trusted-language-extensions, queue, job-queue.
• Repo topics are now visible through the GitHub API.

Leaving this issue open because the broader registry/discoverability work is still a discussion: dbdev / pgt.dev submission, possible META-style manifest, and release/tag indexing strategy.

[NikolayS]

Follow-up PR for release workflow cleanup: #222

No code PR was needed for the first discoverability step; GitHub topics were applied directly to the repo. #222 keeps client release validation unblocked so the library distribution issues can proceed once 0.2.0 stamping/publishing credentials are ready.