pgcentralfoundation

pgrx

Rust2020–2026

pgcentralfoundation / pgrx

pgrx

Build Postgres Extensions with Rust!

Data & Databases

Explore on GitHub Read Hacker News discussions

26Distinct people

36Mentions

1Explicit recommenders

4.8KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Build Postgres Extensions with Rust!

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I love sqlite and rust extension which author has given gets me excited. Last week saw a similar project in rust to built Postgres extensions https://github.com/tcdi/pgx Hope I…

senthilnayagam used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

postgres/postgres · linked in 2 of the same discussions
supabase/wrappers · linked in 2 of the same discussions
vadosware/pg_idkit · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:01:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year36 dated mentions

Observed mentions: 2020-07-13 14:27:39 UTC to 2026-04-25 08:16:19 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	3	1	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	3	0	3
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	11	0	11
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	5	1	4
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	9	1	8
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	4	1	3
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1	0

What Hacker News says

4 sources

K0nserv·Dec 14, 2025

On Thursday I learned about ulid[0] which I think really neatly solves the problem of text representation for UUID v7. However, I also like the idea of prefixed ids, although I haven't used them in anger. Yesterday I built most of a Postgres extension, using the excellent pgrx[1] project, that build on ulid to add prefixes. With it you get something like this plid=# SELECT gen_plid('u'); gen_plid --------------------------- u_06DHRQH6SJT7N2WEQK4910R (1 row) The aim is for it to be the same size as a UUID in storage, but I haven't quite gotten there yet. I haven't pushed it to GitHub yet, but it's fairly done at this point. 0: https://github.com/ulid/spec 1: https://github.com/pgcentralfoundation/pgrx

In Ask HN: What Are You Working On? (December 2025)

kaspermarstal·Nov 9, 2025Submission

LLMs let me maintain my PostgreSQL extension for PRQL after becoming a parent

Gather around kids, it's storytime. Let me tell you about the time AI saved my open source project from my children. Once upon a time there was an open source developer who maintained a PostgreSQL extension for PRQL with hundreds of sparkling stars on Github and he had everything his heart desired. But then, a beautiful woman came into his life and offered him her love in return for his devotion. Enchanted by her looks, the developer accepts without hesitation and walks right into it as she reveals the true nature of her gift: two little shits - errh, kids - who will go on to take all his time away from his computer. Our story began when a critical dependency shipped a breaking change [1] that prevented the extension from supporting PostgreSQL 17. But alas, the maintainer had no time for software engineering. "Fear not girlfriend!", said

Read the rest

the maintainer, "For I will vibe code a fix!". And he summoned Claude Code and touched his keyboard in english places, for he had spent their coin on Claude's Max Plan. For three nights he labored: The first night brought real progress and the model successfully figured out how to return pgrx::Datum via pgrx::RetAbi. On the second night, the model could not generalize its findings to pgrx::TableIterator and pgrx::SetOfIterator because column types were unknown at compile time. On the third night, the girlfriend said "get your shit together and help me with the kids" and branch pgrx-v0.12.9 [2] faded into obscurity. As seasons passed and PostgreSQL 18 was released, users grew disillusioned for their sequential transformations of relational data that starts with "FROM" and not with "SELECT" were stuck in PostgreSQL 16. Ashamed of his abandoned repo the developer compartmentalized his failure, for how could he ever learn to maintain open source projects with two small kids? The answer, as it turned out, was to wait for better models. When Anthropic released Claude Sonnet 4.5, the maintainer tried again. His eyes widened as Claude Code cloned https://github.com/postgres/postgres and inspected PostgreSQL internals exactly as he would have done in a previous life. With the help of WebSearch and a comprehensive test suite that was well understood because it was written before GPT 3.5, the model figured out how to return pg_sys::Datums, SetOf records, and even HeapTuples. By the power of his trust in the tests, the maintainer quickly released v18.0.0 [3] and no longer felt bad about the link on https://prql-lang.org/ that sent thousands of visitors to his repository. Before our story ends, the maintainer asked the model for certain quality improvements. After a couple of "You are absolutely right!" and spectacular fuckups, he realized some aesthetics must be wrought by human hands. And so he made manual refactorings in commits 82dbc44 [4] and d61d04ad [5], pushed v18.0.1 [6], and lived happily ever after. Who needs time when you have Claude Sonnet 4.5? [1] https://github.com/pgcentralfoundation/pgrx/pull/1701 [2] https://github.com/kaspermarstal/plprql/compare/main...pgrx-v0.12.9 [3] https://github.com/kaspermarstal/plprql/releases/tag/v18.0.0 [4] https://github.com/kaspermarstal/plprql/commit/82dbc44808871f60d0cc42b65124faf56f3… [5] https://github.com/kaspermarstal/plprql/commit/d61d04ad735765ef87f4f67d57ecaf0da27… [6] https://github.com/kaspermarstal/plprql/releases/tag/v18.0.1

5 points · Open discussion

tucnak·Jul 8, 2025

Yeah, they would often claim that C API is at fault, but believe it or not, blaming Rust just as much. I've had an interesting discussion with pgrx people: https://github.com/pgcentralfoundation/pgrx/issues/1897#issu... to quote @workingjubilee > Rust has formally rejected the notion that any function can return twice. Even LLVM has no special knowledge of the name of "sigsetjmp" or "setjmp", only that some functions can return twice. > Thus, when you call sigsetjmp or setjmp from Rust, Rust doesn't believe that you called a function that can return twice. The Rust compiler refuses to annotate it with the required LLVMIR annotation. Thus LLVM sees a call to sigsetjmp that it believes cannot return twice... it's just an ordinary function that someone named "sigsetjmp" because they have a sense of humor. What LLVM does next is between itsel

Read the rest

f and whatever gods that compilers believe in, and we have no more voice in such a matter. In this particular case, it's hardly the fault of a "C wrapper."

In # [derive(Clone)] Is Broken

fabianlindfors·May 23, 2025

Glad you like it! You don't need to recompile it actually! It's enough to compile your extension and Postgres can then dynamically link to it, which makes for a perfectly good feedback loop. pgfdb is built with pgrx: https://github.com/pgcentralfoundation/pgrx, which is a framework for building Postgres extensions in Rust that handles all the compiling and linking for you. Highly recommend that if you want to try writing extensions and are also a fan of Rust!

In Making Postgres Distributed with FoundationDB