Hacker News Reader

Comment by dmitrijbelikov | Hacker News Reader

If you understand Postgres's problems so well (though in reality, such problems can occur in many applications, and it's unclear how your rewritten version attempts to solve them), then why not address them in the main branch by becoming a contributor. Less code and more value.

View on HN

I think the issue isn’t a lack of want for fixing these issues, but the inertia and friction of getting them fixed.

The issues around the transaction ids and process per connection are well known, but the changes to the codebase to fix them would either constitute a backwards incompatible change that would change storage needs or an incredibly large rewrite of the codebase that breaks with decades of assumptions.

The json issue is a lot less of a problem as that’s net new. But some of these changes have been debated for years with no movement (and no lack of willing developers to tackle it) and at some point a fork or rewrite like this will happen. In my mind, all LLMs have done is made this work easier to do. If you have reservations about LLM’s doing this kind of work, no one is forcing you to use it, and I think it shows the utility of LLMs in that these kinds of things now can exist.

TID (XID) - VACUUM, AVTOVACUUM (configuration), process per connection - pgbouncer, odyssey

It is explained in the article: Any of those changes require massive or incompatible changes.

So they want 100% compatibility first and then implement features that require massive and incompatible changes?

Checks out, pgrust is mainly an LLM driven rewrite with minimum supervision and guided by 100% test suite conformance.

Sure, why not? Never reaching 100% compatible is a problem as is never amounting to more than a bug for bug clone. If they can quantify exactly what they have changed for good reason then that's good for them.

I applaud the idea to try to do this but for one postgresql tests are not 100% coverage.

So even if they reach 100% compatibility they never get equality.

Then Vibe into that and add changes that breaks the existing coverage...

Why not reimplement the entire thing from the ground up with the changes in mind from the start instead?

The upgrade is an afterthought to a system that is not verified to be fully working and the new features will break the existing verification too.

If I had OCD it would be triggered to the max by this. But I'm just sipping a drink from the sidelines.

Sure, I'm impressed that something like this that would have been a thought experiment or a decades long project with minimal coverage is now a prototype that seems to me like it will contribute something back even if there might not be a rush to use it directly. During the NoSQL phase one can say it was real human engineers making that stuff but often the overall quality was bellow anything that should pass a quantitative measure like a postgres test suite and people put those in production even when they were known to have deep design flaws.

No, this note is another declaration without exact explanation. If you have real bugs you should send a bug report, that's all.

Maybe you should start from bug report without LLM-slop?

Reply on news.ycombinator.com