ads' corner

Where should people start developing with and for PostgreSQL?

The majority recommendations splits between "Read the mailing lists" (30 recommendations) and "help with patches on the Commitfest" (29 recommendations). Far behind in the recommendations is "write a patch and submit it" (12 recommendations). Or to quote Jimmy Angelakos:

Start interacting with the community!

Anything which gives you more interaction with the community, and helps you learn about the development process. This approach aligns with another question:

Does PostgreSQL have a high or low entry barrier?

Now this question is two-fold: the overwhelming majority says that as a user of the database, the entry barrier is low to average. Binary packages are available for all major operating systems, and plenty of cloud providers support PostgreSQL as well. The default configuration gets you far, and a few config changes give you a decent running system for small to mid-size applications. Of course, running a high-traffic database requires more work, but for a small start the database is really easy to use. Add the good support for the SQL standard, and off you go. With the words of Jeff Davis:

I’ll leave it at: “Postgres is a great default”.

That's the user side, or "developing with PostgreSQL". Developing "for PostgreSQL" is a whole different story, according to Dave Page:

Contributing to PostgreSQL can be daunting at first.

It is a long and slow process to get changes, updates, bugfixes or features into PostgreSQL. Or as Anastasia Lubennikova says:

The most annoying thing about PostgreSQL is the pace of development.

The PostgreSQL Project is using git, but not like many other projects. No merges, no public feature branches, no CI/CD system, not many people actually commit to the repository. And Greg Sabino Mullane claims:

No bug tracker. That's pretty crazy. I know Tom Lane fixes all bugs within 10 minutes of receiving an email about it, but still...

In short: even getting used to the way the code for PostgreSQL is developed takes some time and effort. There is a page in the Wiki for new developers, but then again, the process is vastly different compared to many other projects.

Summary

The development process with PostgreSQL is easy, there is plenty of documentation available, Michael Goldberg:

No, the documentation is great and well managed. There are a lot of online resources.

Many related projects, like drivers, are available, and other tools support and integrate PostgreSQL.

But developing for PostgreSQL is a challengy by itself. Takes time. Don't just start writing your patch and hope a round of review on GitHub will do, that's not how this works. The code quality is very high, says Charles Clavadetscher:

Yes. PostgreSQL has reached a very high level of quality in the system itself and the awareness of its existence and capabilities reaches far beyond the community.

But this quality of development requires meticulous reviews, the number of emails on the -hackers mailinglist tell a story. The recommended approach for new developers is to help reviewing other patches first, and get used to the development process. After that, send a proposal of your new feature to hackers, and discuss implementation strategies. Only then start writing code.

Don't forget to check out what other people have to say about the development process, and PostgreSQL in general.