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