Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

github.com

Post reply on HN
Print view View original

101–110 of 756 posts

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#101

Post by pknerd »

fragmede wrote: post #93
pknerd wrote: post #44

I am not trolling, but I have a simple question: Why? Why do I use this instead of the official build? What is the business case?

Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. T…

Well, I will give 7/10 as an FYP

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#102

Post by khuey »

queoahfh wrote: post #50

What a peculiar kind of rewrite. Rust: https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... Original: https://github.com/postgres/postgres/blob/df293aed46e3133df3... Usage: https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... The return type in the rewrite is both some sort of Error tagged union that supports the Try machinery in Rust; but, it also contains a boolean that apparently must be chec…

I make no claim as to whether the change makes sense given that I didn't look at the callers of this function, but Result is an entirely reasonable pattern in Rust. If you want the callers to be able to distinguish between "has the subclass", "doesn't have the subclass", and "something went wrong" this is idiomatic Rust.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#103

Post by verytrivial »

cyberjar wrote: post #83

I'm starting to get a bit of fatigue for these projects that boil down to just "I asked Claude to re-write this code into a new language that's in vogue right now!" I really don't understand why this is needed outside of an opportunity to show how impressive LLMs can be when working within large codebases, but even then people in the comments are finding bizarre implementation choices that a human developer wouldn't…

[dead]

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#104

Post by bakugo »

dirkc wrote: post #78

How would one go about reviewing a piece of code like this? One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you mu…

Vibe code was never meant to be reviewed.

These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done.

In practice, this is never true for any codebase above a certain level of complexity, especially not one as mature and widely used as Postgres. But reality doesn't seem to be an obstacle for vibe coders.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#105

Post by scotty79 »

Rewrites in Rust are kinda impressive. This language with its move semantics and close ownership tracking is very different from every other language. To create a rewrite in it, you have to rearchitect the code. There is not as much freedom there when it comes to where to keep what and where you can pass what as it is in other languages.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#106

Post by m00dy »

dixtel wrote: post #64
ottavio wrote: post #33

Why should a developer use this for anything beyond a pet project? Just because it is written in Rust? All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.

> software talibans I will note that, very funny

what does it mean ?

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#107

Post by evil-olive »

> The goal is to make Postgres easier to change from the inside

uh-huh, sure.

you want to show off "look what the LLM can do / look what I burned a bunch of tokens on"?

you want to brag about how your LLM-generated slop is somehow more maintainable than the original because blah blah blah Rust?

here [0] is the version history of Postgres. pick a version from the past. let's say 14.x because it's the most current that's still under active support.

have your LLM implement version parity with 14.x. show off how it passes all the tests blah blah blah.

then have it upgrade your codebase to parity with 15.x, implementing whatever new features and bugfixes that includes.

and have it generate an automated test that demonstrates upgrading an actual database from LLM-14.x to LLM-15.x and verifying there's no data loss or corruption. maybe even multiple such tests, if you're feeling fancy.

then lather, rinse and repeat with 16, 17, and 18.

and show off the diffs of each version. does the LLM rewrite a huge pile of already-working code in the process of each version upgrade? does it introduce new latent bugs in the process - the kind of things the existing test suite didn't think to explicitly test for?

"I took a static snapshot of code and converted it to another static snapshot of code" is meaningless. all you're doing is bragging about having more money than good sense.

the stability and trustworthiness of software like Postgres does not come from a one-time snapshot showing tests passing. it comes from the engineering process that produces the software and its test suite.

oh, and for shits and giggles, because this same test was so illuminating with the Bun "rewrite" into Rust, here is the file with the most unsafe blocks in the codebase:

    > rg -c unsafe crates/backend/parser/gram_core/src/convert_ddl.rs
    128
    > wc -l crates/backend/parser/gram_core/src/convert_ddl.rs
    2055 crates/backend/parser/gram_core/src/convert_ddl.rs
why does a single 2000-line file have over 100 unsafe blocks?

why is the parser unsafe at all?!?

0: https://en.wikipedia.org/wiki/PostgreSQL#Release_history

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#108

Post by geraneum »

arka2147483647 wrote: post #79
ottavio wrote: post #33

Why should a developer use this for anything beyond a pet project? Just because it is written in Rust? All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.

Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything. Cue some story here on a bank or airline somewhere still relying on cobol backend servers. These LLM conversions really seem to make modernization of large parts software layers possible!

> Cue some story here on a bank or airline somewhere still relying on cobol backend servers.

There's existing money and expertise in those environments to rewrite the whole thing, yet they don't. You may loan them free engineers/experts and they might still not rewrite anything.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#109

Post by DuncanCoffee »

dirkc wrote: post #78

How would one go about reviewing a piece of code like this? One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you mu…

The github cli has a command to query commits with a sorting asc/desc flag

https://cli.github.com/manual/gh_search_commits

here's the docs with more syntax using the "before x date"

https://docs.github.com/en/search-github/searching-on-github...

there's also an advanced search page, but it does not support commits when filtering with dates

https://github.com/search/advanced

or you can bisect the date in the search widget, this is the first day with a commit

https://github.com/malisper/pgrust/commits/main/?since=2026-...

first commit:

https://github.com/malisper/pgrust/commit/22113dc36b02973060...

Post reply on HN