A thread per connection is a almost always the correct decision for performance, but by choosing a process per connection, postgres is able to let you load whatever sketchy extensions you want. Worst case you crash the process, not the database. It would be nice if you could strike a balance so a segfaul in the extension only crashes a small percentage of connections, not the whole thing.

I don't want to knock you down as most have already did. In-fact it's a useful exercise going forward in exploring how to work with AI. It's here, we're all going to use it one way or the other. Zero issues with that, in-fact kudos to going through the pain of it all.

Now, having gone through several such endeavors originally myself, albeit with internal tools and systems (as an exercise), I've noticed that while all my tests passed with flying colors the rewrite itself was broken even on basic functionality or missed a ton of details. It was in effect useless when I dived into it. Initial tests also showed massive gain in performance, and I know people who were involved aren't really dumb so something smelled funny. Turns out all those things left out and honestly... moments were the key ingredients.

What I did learn from those beginning explorations though was that one-shotting, grand architecture or source up-front, master plans up-front.. all these do not yield good results - YET. Who know what we'll see in few years though. What I did found that works (FOR ME, nota bene) is to keep the design and checklists for myself, written by myself and then do a small piece by piece.. as if you would if you were coding alone or if you would waterfalling a small team of talented juniors. Then, suddenly super happy results come out, but then it's mostly you driving all the way where llm writes code and offers advice (which for the most part you ignore). It's a happy place for myself at least. It's then truly unlocking yourself to the mythical 10x.

Rewriting a large proven system with decades of ultra expertise behind it, which I don't have, is guaranteed not to end up the same 1:1 replacement. If you found a recipe for that - please do share.

Ouf. I don't know. I don't want to call you out without evidence -- I myself make benchmark claims all the time -- but 50% improvement in OLTP seems suspicious. I get that you used a standard benchmark, and I don't even know what it entails, but my spidey sense is going off. Perhaps, some trade off somewhere that won't make it to prod because it breaks MVCC -- and yes, I saw that it passes regression tests.

Just checking, is fsync on? :) Regression tests don't catch bad IO patterns afaik.

Anyway... sounds like a fun project to work on!

What's your actual background and expertise with Postgres and databases more broadly? Basically, do you actually know what you're doing, or is there likely a massive footgun you don't know or haven't shared with us?

> - Is ~300x faster than Postgres on analytical workloads. Right now it's 2x slower than Clickhouse on clickbench and I think it's possible to get faster than Clickhouse

That sounds like you are storing the data in a columnar format? Or do you do both row and columnar?

In a somewhat similar (yet also quite different) effort, I've been working on δx, a Postgres extension that compresses the data in a columnar format stored in normal Postgres tables (so replication, crash recovery, pg_dump, etc. still work normally). https://github.com/xataio/deltax

It is currently about 30-40% slower than ClickHouse (single node, ofc). The PR to add it to clickbench was just accepted, so you can see the comparison here: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

It doesn't sound like you were trying to launch a product, but doing an experiment and someone threw you under the HN-spotlight-bus :) Is this a "see what I can achieve with LLM coding" or is this "build this and see how much of the coding can be accepted from LLMs"?

What was your methodology and structure in making the prompts for the rewrite? Did you let the LLM roam in all of the codebase and tests from the beginning, or revealed things to it gradually in some way?

Are you fixing the heap and table management ?. Postgres does not use an undo log and manages all table updates directly in table storage which slows MVCC.

also have you told Ben Dicken ? https://x.com/BenjDicken/status/2074326407795417435

"Is 50% faster than Postgres on transaction workloads" - That is a very big claim! 50% faster on everything? Is it a strict improvement across the board or are there tradeoffs that make some workloads slower?

While a thread-per-connection seems like an improvement, do you have any plans to allow query multiplexing over a single connection? That would be a huge improvement IMO.

> build a better version of Postgres

Faster is quantifiable. How do you measure better?

This is great! Those analytical workloads numbers are mad - I'd love to see the benches, and I'm happy to contribute to some of the profiling.

How does your thread-per-connection model compare to Heikki's proposal[0][1] from back in 2023?

[0]: https://www.postgresql.org/message-id/31cc6df9-53fe-3cd9-af5... [1]: https://www.youtube.com/watch?v=xLLakMmVtbY

Is it being used in production anywhere, even if only a toy app?

I know you say it's not production ready and not optimized yet, but in the same breath - in your comment here - you say it's already faster.

Super impressive! Is it possible for you to share your methodology of using LLMs?

PG Wire proto 3 is my largest source of frustrations.

I'm playing with a POC for a better wire protocol here: https://github.com/solidcoredata/pgwire4

I am super curious how you went about the port using LLMs. At $WORK we are looking to port code, preferably with LLMs, and it seems daunting, even with a test suite. Do you have an approach that works well for you?

Just a couple of ideas if you run out of backlog:) - proper versionnumber (64bit) - native json streaming. It would be awesome to get to the point where i could somehow redirect the sql output to the browser directly, but piping will do for now. The idea is to be able to stream rows to client without caching and building json along the way.

It's a completely new era of software production (I will no longer call it development) LLMs give us unlimited manpower, and the language give us constraints to make more modern and safer softwares. Love to see this rewrite in Rust, and expecting much much more in next few month.

How much of the performance gain is from using Rust, compared to using optimizations that are not done in the original PostgreSQL code (like using threads instead of processes, etc.)?

I am simply curious what the benefits of using Rust are in this instance.

Do you have anything in the regression test suite like jepsen etc?

when doing rewrites like these, why isn't the first step to instrument the original code so that you would get very good automated test suites to point the LLM toward?

use both synthetic and real data to sample the internals of the original software to duplicate.

locate all the data transformation junctures, sample and then replicate the tranforms 1:1 in the rewrite.

Would you like to submit to ClickBench?

I can also do it if you would prefer...

That…is really impressive. Well done!

300x is mostly a marketing term, especially without the test description.

BTW, showing no respect to what it is trying to copy looks uncomfortable.

i highly doubt you can make it faster than clickhouse, but happy to see it.

Is it your first rewrite/migration (with or without llm) ?

good luck nonetheless

Awesome work. I'd love to see you add something like kusto query language or pql. The autocomple on kusto, (which can be embedded into web apps) is really amazing.

This is how to LLM. Big ups, I wish the whole front page was stuff like this (and I think it'll happen).

Everyone is so worried about the value of commodity software going to zero. It's like, yeah, going into CS for the money always looked dumb to me, it's just not a good career path for that, you have to love it.

I am way more excited about a whole new class of stuff that obliterates the state of the art at every frontier.

Keep doing it legend.

I'd be interested to hear the author's answer to your question, but I see it as an interesting proof-of-concept. It's testing the viability of not only rewriting PostgreSQL in Rust (and their choice of deps) but also in switching the threading model and other architectural changes. LLMs shine at pumping out prototypes insanely fast, and a working prototype can put an end to a lot of speculation.

I likely wouldn't use a rewrite of such a huge project if it doesn't have the backing of the original team (or a significant fraction thereof) and a believable story for having matched/exceeded the original code quality and maintenance. I also think in general using an LLM for license-laundering is legally and morally hard to defend, although this case is different in that they chose a more restrictive license. Not a lawyer, but my understanding is that you can just download PostgreSQL, do s/MIT/AGPL/ and release it, legally. (The original MIT-licensed version still exists, so no reason anyone would prefer yours until you make another release with some compelling new feature.)

It's a very interesting phenomenon in recent years and most of the discussions about "why" are immediately blocked by the "memory safety" argument, as if it's a silver bullet for all things that are considered "bad" in software implementations. No matter how good the language is, and I consider Rust a very good language, it's practically impossible to replace years of experience and tested code, most of it contributed by a ton of brilliant programmers, no matter how you look at it. And if we take this as the truth, then logically there's still an unanswered question - why? Lets take an undeniable fact - rewriting an existing project give you full control over the new implementation. You can do whatever you want with it, you can't be sued. The only thing now you have to hope for is for your implementation to gather a good enough user base and from then on you can practically hijack the original project. And this is me speculating - rewriting stuff in Rust isn't about the greater good for that magical "memory safety" argument, but at the end it's an attempt to hijack popular software projects.

This is very critical of an open source project that the maintainer didn't even post here?

"Status:

pgrust is not production-ready yet. It is not performance optimized yet."

The maintainer is not suggesting you use this for anything yourself. So why do you care about spf or (lol) his "discipline in creating the project"?

It's not just a rewrite ; it has improvements. I did the same thing for fun for the same reason; I wanted to see if I can improvements on some of the legacy design stuff and, especially, the stuff PG people have told us that it cannot be done differently. It can. I would not put it in production, but it thought me a lot about the internals of databases. To keep my brain happy in the age of LLMs, I implement database things on our (also old but many times refactored/rewritten) production db without an LLM. I'm sweating through Flexible Paxos now; probably we will just keep using raft as it's old and stable and simple but it's interesting anyway.

It’s open source. You take ownership of it for your deployment and stop relying on continued free work.

You can use llm to pull in updates as they are released. It’s not gpl, so you don’t need to publish your port

It's useful to show the actual team that it's possible. From there, they can make the decision of whether to go the bun route with more information.

> it’s increasingly difficult to maintain these projects without AI

It's pretty much impossible in a project of this size. IIRC Postgres has over 1M loc.

I'm really happy to see these rewrites. It shows what's possible, especially as the projects get more and more complex.

And maybe Remacs will get reactivated https://github.com/remacs/remacs/wiki/Progress

Maybe even I'll be able to do it when I wait for the bus!

Not the same but it is much faster and easier to re-create a 3d model of an existing set of drawings than from scratch. This is because a lot of the decisions have already been made.

>typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term

Lindy effect! The longer something has been around, the longer it probably will be.

https://en.wikipedia.org/wiki/Lindy_effect

I guess it is cool to have it around but it comes off as a popular useful case for AI which it really isn't, unless you have a very good test suite to throw the agent against, it is practically useless for rewrites of decades old badly documented code riddled with technical debt. That is where the real value and challenge would be. I see it as marketing and social clout stunt

Everything has to start somewhere

> So, who wants to put something like this in production?

I don't think anyone suggested deploying this to production - the author is quite explicit that it's an experiment.

spf meaning...

This year, not me.

In five? Everybody but me.

If you were a token burning company a project like this seems like a solution to this: https://xkcd.com/2347/

that hits your metrics without the problem that your contributions are not welcome.

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.

(I'm working with malisper on pgrust),

I think the focus for projects like this is going to shift to reviewing the testing/fuzzing process instead of reviewing each commit (going much further than what the postgres regression/isolation/crash tests do).

related post from danluu: https://danluu.com/ai-coding/

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...

> ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious

I usually check the history of a file not easily changed like .gitignore.

The first commit seems to be this one

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

> How do you easily get to the first commit in a repo on GitHub?

You can use the syntax github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 (-1 for the latest and -1 for the last)

ex : https://github.com/malisper/pgrust/commits/?after=3646a73515...

I started by looking at the dependencies.

Then I lost count, so I ran wc -l Cargo.lock

   1467 Cargo.lock

In general (I’m not saying this is the case with this project) if you don’t have their prompt history and you can’t re-run the LLM “compilation” yourself, is it open source? It feels a bit more like those “source available” projects where you can read the code but don’t have access to the build system.

On the other hand, aside from the commit messages, one didn’t ever have access to the underlying thought process of human developers either, so maybe it’s not equivalent to say that secret prompts mean closed-source.

You don’t. You trust that passing the regression tests means you are totally compatible with the original version.

> 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

I could not care less about any of this. Truth is code, as it is now. I don't care when (and certainly not by who) a bug got introduced, it's here, shut up and fix it.

[dead]

> How would one go about reviewing a piece of code like this?

That's a wrong question. The right question is "why would one go about rewriting a piece of code in X". Once and if you find a good answer to that question, you will see the answer to your's.

Can you control the timing of queries across two db instances well enough to expect the tables to be identical?

Note that most of the unsafes are confined to the parser which was generated by running c2rust over the Postgres parser. The Postgres parser is itself generated from yacc/bison, so I decided to port it over mechanically rather than idiomatically.

If there's particular unsafes that you think are egregious, let me know.

Counterpoint: All of the current Postgres codebase is already wrapped in an invisible unsafe{}.

The difference with a Rust codebase like this is that all of the unsafe code has been neatly isolated and clearly marked. The outside code is safe — at least according to the definition of what Rust considers safe, which is a high bar indeed and objectively superior to the unsafe mess that is C — and the unsafe code is naturally fenced in, which means that it can be seen by developers and tackled by incrementally.

In some cases unsafe is unavoidable, but it is possible for a human to verify that it is, in fact, acceptably safe even if inside an unsafe block.

I set all my Rust LLM written projects to 'unsafe=deny'. Not sure why not everyone is anticipating your comment.

Let me just copy this review comment into my prompt.

a few hours later

Fixed!

Why even use rust...

You seem to have the restrictiveness backwards? The MIT license (uutils coreutils) is less restrictive than the GPL (GNU coreutils), and the AGPL is more restrictive than the PostgreSQL license.

And it doesn't violate the PostgreSQL license to license the rewrite more restrictively. That's part of what makes MIT-style licenses less restrictive than the GPL or AGPL: they allow for more-restrictive relicensing.

If you don’t like the license just let an LLM spend a few days “porting” it and give that port any license you like because that is apparently what we do now.

The PostgreSQL License is a variant of the BSD license and is therefore compatible with the (A)GPL.

Comprehend it this way: You create a blank (A)GPL project and incorporate the upstream BSD codebase into it. While those original upstream files remain under their original permissive license, the project as a whole is governed by the (A)GPL (plus the attribution requirements of the upstream license, which the GPL permits). From there, you can add your own code under the AGPL and distribute the combined work under the AGPL.

If someone takes your code and uses only your portion, they can use it under the AGPL alone. However, if they also include the upstream source code, then the attribution requirements of the upstream license must still be met.

AGPL and copyleft licenses are not restrictive, they provide forward (open source) guarantees. The only thing they "restrict" is the ability to remove freedoms. Therefore is not a restriction, is a guarantee. A guarantee that the project will endure as open source.

I wouldn't go as far as calling permissive licensing "restrictive" because they actually allow for reducing freedoms; but copyleft is definitely not restrictive at all, it's the opposite.

Having said that, I like and appreciate both kind of licenses and I have and will continue creating open source software using ones or the others.

The Postgres license is already fully compatible with the AGPL. BSD/MIT is more permissive.

Wow, yeah, really hate this.

If this software was written by a mechanical process, the license is a nullity. It’s public domain.

For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.

Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.

So how much AI usage does it make it an “AI rewrite”?

A human rewrite without maintenance is just a hobby project. An AI rewrite is just wasting tokens for god knows what?

rewrites feel like an area where LLMs are better suited than humans imo

It’s mostly grunt work and LLMs are well suited for translation tasks (iirc transformers arch was originally invented for translation)

It’s just a build step now.

nope. any rewrite will be an AI rewrite soon.

It's not that... It's a rewrite by project maintainers vs a fork.

We already have a well established term for AI rewrites.

I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!

It is more and more the future. No human would want to rewrite one technology to another because it is too marginal a gain. AI on the other hand does not give a shit.

I'd %100 prefer an opus 4.8 rewrite over %99 of the time. Unless Fabrice Bellard is rewriting the stuff I need, I'd prefer AI over a human coder.

Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?

AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.

His project is cool. Students could use it as an example of porting code. Companies could switch to it, if it works. There are hundreds of reasons why people may want it, so it's awesome he's publishing one. Something needs to be done to get interest and then adoption.

Just keep using the proper Postgres project if it makes more sense to you. But notice that this isn't just a strict translation, it actually makes changes (moving from process to thread based design, for instance). Time will tell if people find these changes beneficial or if the original remains preferable.

It's also worth noting, that while you are able to use LLM's to produce your own translation, he's actually done it. There's value in actually putting in the work.

This isn't a unique situation at all. Many Postgres extensions are developed and maintained by a single person, and may therefore be avoided by more conservative users, even if they offer some technical advantages. To each, their own.

There’s no claim being made that your rewrite cannot be better.

He has provided benchmark results which provide a dimension amongst which to measure your rewrite. If you can do better by all means post your rewrite.

Finally, these kind of projects can eventually over time become projects that are actively used. Postgres is not some entity that existed before the universe was created; it was also created by someone and then eventually adoption picked up over time.

Came here to the same thing. I did something similar (but bolder, it doesn't slavishly copy Postgres and is based on current DB research papers and the like, and other bits I've been exposed to over the years). It has a full TPC-C-esque benchmark suite, replication, embedded v8/JavaScript relations/stored procedures, a giant suite of regression tests, it kicks the crap out of a lot of existing OLTP DB stuff out there. And I personally do have a background in commercial DB development.

But I choose not to publish it or promote it for many of the reasons you mention above (and more)

... For one, if "I" can do it, so can a hundred other people. And all the bold claims behind it would need to be backed up and supported and it promoted, etc, which is a whole pile of time that doesn't involve writing code.

It's the organization around a project that matters, not the code. It's not the 90s anymore w/ people piling into MySQL because it was the only option. People aren't going to be trusting your software with their data, if they can't trust you.

And unless someone is going to dump a pile of money or something on [me|them], I don't have the ability to build that organization ... as I need to feed my family... Nor am I willing to put my personal reputation on the line by putting up a huge quickly written application and then someone finding something in it I can't explain.

So like probably 500 other projects I have it sitting in a private repo.

It's a very weird time right now. "Technical" excellence isn't the important part. Organizational excellence is. This was always the case but it's more so now.

... In the meantime, if anybody has angel investment to burn, I have something potentially better/more-exciting than this guy's project but... see above...

> If you can do a Rust rewrite with AI, I can create one as well.

Translations are a lot more likely to be error-free and robust, as the original data structures and algorithms have been battle tested.

> not mostly the test, but the real world production scars

Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.

SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some guarantee of equivalent diligence.)

And yes, years and years of running.

I agree. I also agree with the sibling reply that -

> every time you have a bug or a regression, you write a test that confirms correct behaviour.

What I fail to see in these rewrites however is - what about new bugs introduced by virtue of this rewrite? I mean it'll have to go through its own challenges in real-world scenarios, right?

> I start to see a lot of these re-writes that depend on tests to state that its working.

There's another way to validate the rewrite though. Just run both pgrust and postgres and compare the output. Know of an edge case? Run it too. Doesn't know? Use a fuzzer or some automated tool to find interesting inputs. Found an inconsistency? The input/output pair becomes a test case now

Not sure if there's tooling for that though. If there is, just give it to Claude so they will incorporate it in their development loop

Not weighing in on this specific rewrite but tests are how you specify that your software works correctly. If a behavior isn’t covered by an automated test in some form you can’t assert that any given change doesn’t break it.

I think it is completely reasonable to use a preexisting unmodified test suite to state that something is working. The larger the project the more true this becomes. Real world production scars are documented and guarded against in the test suite otherwise those lessons get lost.

Also SQLite is legendary for its massive test suite and extensive fuzzing. They have 590x the amount of test code and scripts than normal code. Source: https://sqlite.org/testing.html

Great point. Stated another way:

"Mom, can I have battle-tested, reliable software"

"We have battle-tested, reliable software at home"

Battle-tested, reliable software at home: (Pic of green text from `cargo test`)

Completely agree with this.

The biggest lie of software engineering is that everything can be testable with tests. That a 100% test coverage is an indicator of quality software.

> That's where the reliability comes from

So, we should make it easier to feed that reliability back upstream.

Probably the most useful thing you can do with these LLM-transpilations for now: If the transpiled version passes all original tests, I can run my application test suite against it and use it to discover test coverage deficiencies in the original!

If it crashes or otherwise observably misbehaves, I know the real project was missing regression tests for something. We could make upstream so much more resilient against accidentally breaking stuff in future updates, if only it becomes safe (offline + no side effects) and easy (if it crashes/locks, it is not from some memory safety bug from 25k transactions earlier) to run these transpiled projects as one row in our everyday integration matrix.

As sibling mentioned - bugs and regressions are the thing that are (in a perfect world) usually covered.

The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.

And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.

Now the new, test-based implementation, has to prove it can handle remaining 99%.

That's precisely what a regression test suite is for. There is a bug, you fix the bug, you add a regression test. So if the test suite is well maintained these real world production scars are reflected in the tests.

And also the amount of people running it in thousands of scenarios. Not sure if these areas can be even tested for, but I guess time will tell (can observe Bun if it breaks somewhere as that’s afaik the first big AI rewrite which got into prod for masses).

I hope you are not true at all.

Software like a Database should have an extensive test bench with concurrency tests, all corner cases etc.

I'm not here running the new version on production to tell the maintainer/devs that my 'production unit tests failed'.

What is this even for logic?

I mean there is balance when i write tests for my production software, but my software is used by me. If i would have a library, i would test everything.

And there was some blog post about another database system were they even virtualized the File access to test cases like when the disk controller stops working.

"Everybody has a production system. The lucky ones also have a test system."

Wait - does the AI rewrite the tests too? If so, lol.

`Cargo.lock` is a lockfile machine generated by Cargo. It's similar to package-lock.json. In any case, its machine generated the old fashioned way.

Like most modern languages, Rust has its own build system and package manager, Cargo. Everything you're referring to relates to that, and has nothing to do with LLM coding.

Edit: saw the clarification in another comment. But, in that case the essential point seems to be "I'm not familiar with something, therefore it's suspect."

> I love llm coding. I don't know what I am looking at here

There might be some correlation here.

From what I skimmed manually, not that many, but the code itself seems labyrinthical. Like, why have both Rust Try-supporting Error-like tagged union, but also booleans, for error handling, in the same function?

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

When the software consists entirely of ~$1000 worth of Claude credits and ~40 hours of developer time prompting and curating it, literally what does it matter what license the resulting 100k LoC artifact is provided under?

Copyleft and the whole software licensing ecosystem only matter when producing that software actually requires serious human effort and dedication.

It is theoretically possible to have a Rust port of Postgres support extensions. If you make all the relevant functions and structures ABI compatible with Postgres, extensions should work. The issue is the moment you're dealing with C pointers and C strings, pretty much all the code you have to write is unsafe.

They would need to be rewritten as there is no formal extension API. Extensions can call into almost any part of PostgreSQL.

They would need rewriting (a few are included)

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<bool> 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.

It is a feature in Rust, not a bug :-) (I know you didn't say it is a bug.)

The error-tagged union is PgResult<bool> - which means it contains bool as the result if things go well. (The other part in the union is of course the error.)

In the original function also, it is returning a boolean: "bool has_subclass".

So anyway you have to check for the boolean as part of the logic. That is what it is doing.

And they'll reproduce virtually the same problems, because code was never a primary issue for output. Products reflect organizational problems, which AI can't solve.

Also, are they calling it Postgrust?

related? https://www.youtube.com/watch?v=e35AQK014tI

Yes, see top comment.

How do you know it's not SQL-lite with the single L serving a double role?

Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other.

AFAIK there is no official word on how the name is intended to be read or said.

I mean, you've linked to a function performing md5 hashing. That's pretty much exactly what I would expect such code to look like.

Case in point: https://github.com/postgres/postgres/blob/master/src/common/...