The first commenter on the blog makes a very good point:
> The thing I like to remind people is that this project has been around for decades, during which over a hundred people (or whatever COUNT(*) FROM contributors is) have picked through the code trying to find low hanging fruit to contribute. Everything left to do is astonishingly hard; if it weren't it would have been done already.
There are no easy wins left to contribute.
I've had ideas for a few pg extensions, I wonder if these are as difficult to contribute.
Development-wise they're completely different. Extensions are much easier / more isolated.
Developing a pg extension is all about compiling some C code into a .so object and dynamically using a templated Makefile to load it into the running Postgres process.
I don't think that's true. Watch the pgsql-docs mailing list and you will see a steady stream of people pointing issues in the docs.
Moreover, there is a steady stream of new features. New features that need polish and docs. I've got a patch in the mailing list (maybe, hopefully, knock on wood) to add the first code samples to demonstrate Table Access Methods.
For that matter, I don't think there has yet been committed an a second /dev/null or in-memory Table Access Method. Though I'm aware of one person's effort to add a /dev/null Table Access Method. But I don't think this has been merged yet.
This is unrelated to what Robert is talking about though. I don't love the contribution process. But there is definitely a lot to contribute to if you do spend time and keep an a eye out for where improvement might be useful/accepted.
I'd say hacking isn't the same as building new production quality features.
Just for fun or for educational purposes, I'd want to change something about the database, and it won't be easy because internals aren't that well documented beyond code comments and C makes it hard to find what's what (no rust-style docs or code map).
Given months of digging around I'm sure I'll be able to do something small, but "hacking" is a side gig, not a full-time job.
> The thing I like to remind people is that this project has been around for decades, during which over a hundred people (or whatever COUNT(*) FROM contributors is) have picked through the code trying to find low hanging fruit to contribute. Everything left to do is astonishingly hard; if it weren't it would have been done already.
There are no easy wins left to contribute.
I've had ideas for a few pg extensions, I wonder if these are as difficult to contribute.