Hacker News Reader

Comment by RedShift1 | Hacker News Reader

Hot take: this is good? It's a database, you want it to be predictable and reliable as it's literally the foundation of many applications and processes. It's not another toy project, mistakes can have disastrous consequences so you really want those extra layers of scrutiny.

View on HN

The main problem this post complains about is that it's difficult to implement changes correctly, even as an expert. That's definitely not a good thing.

I read the article and I can’t understand at a simple level why it’s hard to contribute. Is it easy to break things? Is it hard to determine if something is broken ? If so, maybe it just wasn’t really designed with those items in mind, or maybe there just isn’t adequate testing.

Adding on a new feature that is hard to understand is maybe a signal that the design does not support it.

Yes but it's a database server, I expect lots of things to be non-trivial here?

Sure, but the design should make it reasonably efficient and reliable to reason about the behavior. The assumptions, requirements, and guarantees should be clear (documented) at all relevant code locations.

There is a lot of mentioning of testing in this thread and in TFA. However, testing is not the main tool to achieve correctness. Testing is merely a sanity check. Correctness is achieved by being able to adequately reason about the logic of the code, making sure that all assumptions and guarantees are met.

TFA sounds like that reasoning is hard in the PostgreSQL code base. But it could also be that the author was approaching things in a too cavalier manner.

Expected doesn't mean good though.

Sure, but is there any other mature and complex (or even more complex) database software easier to hack then Postgres? I imagine something like Microsoft SQL is just as hard and Oracle is known to be a complete mess, much worse than Postgres in this regard.

Reply on news.ycombinator.com