On query guardrails: every query runs in a readonly transaction and results are capped at 500 rows via a wrapping SELECT * FROM (...) sub LIMIT 500. There's also explain_query which returns the plan without executing, so agents can check before running something expensive. That said, there's no cost-based gate that blocks a bad plan automatically; that's an interesting idea worth exploring.

pglens gives agents the context to get it right the first time: column_values shows real distinct values with counts, find_join_path does BFS over the FK graph and returns join conditions through intermediate tables, describe_table gives columns/PKs/FKs/indexes in one call. Plus production health tools like bloat_stats, blocking_locks, and sequence_health.

Everything runs in readonly transactions, identifiers escaped via Postgres's quote_ident(), no extensions required. Works on any Postgres 12+ (self-hosted, RDS, Aurora, etc.). Two dependencies: asyncpg and mcp.

https://github.com/janbjorge/pglens

pip install pglen

Comments URL: https://news.ycombinator.com/item?id=47564620

Points: 13

# Comments: 7

Comments URL: https://news.ycombinator.com/item?id=47494195

Points: 3

# Comments: 0

GYML is a strict subset of YAML. Valid GYML is always valid YAML. It keeps the block indentation syntax and pairs it with JSON's type semantics: one spelling for each type, no anchors, no aliases, no tags, duplicate keys are a hard error. From-scratch parser, no runtime dependencies, fully typed Python.

https://github.com/janbjorge/gyml

Comments URL: https://news.ycombinator.com/item?id=47302509

Points: 1

# Comments: 0

EDIT; HN trims the full url to readme about in-memory https://github.com/janbjorge/pgqueuer?tab=readme-ov-file#in-...

Comments URL: https://news.ycombinator.com/item?id=47210945

Points: 2

# Comments: 0

How it works

Read the JSON file, modify it in memory, write it back with compare-and-set. If two workers race, one wins. The loser retries with fresh state. No locks needed.

Inspired by; https://turbopuffer.com/blog/object-storage-queue

Comments URL: https://news.ycombinator.com/item?id=47144842

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47094172

Points: 1

# Comments: 0

It uses the same core primitives people are discussing here (FOR UPDATE SKIP LOCKED for claiming work; LISTEN/NOTIFY to wake workers), plus priorities, scheduled jobs, retries, heartbeats/visibility timeouts, and SQL-friendly observability. If you’re already on Postgres and want a pragmatic “just use Postgres” queue, it might be a useful reference / drop-in.

PGQueuer is a small Python library that turns Postgres into a durable job queue using the same primitives discussed here — `FOR UPDATE SKIP LOCKED` for safe concurrent dequeue and `LISTEN/NOTIFY` to wake workers without tight polling. It’s for background jobs (not a Kafka replacement), and it shines when your app already depends on Postgres.

Nice-to-haves without extra infra: per-entrypoint concurrency limits, retries/backoff, scheduling (cron-like), graceful shutdown, simple CLI install/migrations. If/when you truly outgrow it, you can move to Kafka with a clearer picture of your needs.

Repo: https://github.com/janbjorge/pgqueuer

Disclosure: I maintain PGQueuer.

But seeing how they just treated Hack Club — sudden 40x price hike, almost no notice, threatening to cut off access and delete 11 years of history — makes me wonder if we should rethink where we build our work.

I don’t want to leave Slack. But I also don’t want to wake up one day with our team’s history held hostage.

https://github.com/janbjorge/pgqueuer

I’m the maintainer of PGQueuer, a minimalist job queue for Python that runs entirely on PostgreSQL—no Redis, brokers, or additional infrastructure required. It’s designed to offer solid concurrency with low overhead and fit seamlessly into projects that already use Postgres.

I’ve been working on improving the public documentation [1], and I’m looking for feedback from others who’ve gone through this process—especially those maintaining small, technical open-source projects where all the important knowledge lives in the docs. There’s no internal documentation and likely never will be, so clarity and accessibility are essential.

I’d especially appreciate your thoughts on:

* How do you decide what’s worth documenting for a technical audience who might just read the source anyway?

* How do you balance being thorough without overwhelming the reader?

* I’m currently using Read the Docs [2], but I’m considering switching to a self-hosted MkDocs site. What have your tradeoffs been between Read the Docs and self-hosting?

* What practices have helped you keep your docs in sync with your codebase?

* What’s worked well (or poorly) for encouraging contributions and getting users to help improve the docs?

If you have time to browse the current docs [1], I’d love to hear what’s missing, what’s confusing, or what stands out as helpful.

I’m here to learn from your experience—tools, workflows, hosting decisions, contributor strategies, anything. Thanks in advance!

---

[1] https://pgqueuer.readthedocs.io/en/latest

[2] https://readthedocs.org/

[3] https://github.com/janbjorge/pgqueuer

Comments URL: https://news.ycombinator.com/item?id=44087090

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=43780520

Points: 48

# Comments: 4

Even with clear photographs and detailed instructions, LLMs tend to give general advice or indirect methods rather than precise, actionable steps that clearly demonstrate correctness.

Have you tried something similar? Have you successfully "prompt-engineered" an LLM into giving clear, precise, step-by-step solutions for physical puzzles? If yes, what's your approach?

Comments URL: https://news.ycombinator.com/item?id=43671966

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=43194537

Points: 1

# Comments: 0