How and why to become a PostgreSQL contributor | Hacker News Reader

How and why to become a PostgreSQL contributor

blog.timescale.com

While I completely support this type of article, I think it still doesn't really help someone get started on meaningful features. It is my impression that you need to be really embedded in a community (or work for a company that runs the community) to hear about and get a chance to work on meaningful features.

Thankfully there are alternatives! My favorite thing to do when trying to learn a new large FOSS codebase is to implement some redundant function like a plus (+) operator. If you do that in Python or PostgreSQL you can mostly copy-paste from existing functions (don't actually look at the exact one you're copying) and it will take you through the language frontend (lexer/parser) and backend evaluator.

You can do this same kind of technique whether it's a language or not. Just take some kind of redundant feature and copy existing features/modifying as you go along.

I wrote about doing this kind of thing for nginx, as an example: https://notes.eatonphil.com/learning-a-new-codebase-hacking-...

You'll learn a lot about the architecture and build process within a few hours.

Reminds me that PostgreSQL goes way back and has had some notable contributors -> https://gist.github.com/tmc/81b917d39b4b752029fd

Is that really THE Julian Assange?

Looks like it, his Wikipedia page [0] does mention "In the same year, he was involved in starting one of the first public Internet service providers in Australia, Suburbia Public Access Network"

Which matches the contributor's email domain name suburbia.net

[0] https://en.wikipedia.org/wiki/Julian_Assange

Yes: https://news.ycombinator.com/item?id=1973777

This is mentioned in the article, but one thing I'd call out that can't be understated is reviewing patches and testing. This has been for years and continues to be an area that more help is always very welcome. It's a great way to get your feet wet, and try to chip in to the overall quality of Postgres. Even now looking at the commitfest app[1] there is quite a few patches that anyone could jump in and try to help review.

[1] https://commitfest.postgresql.org/33/

I think it's difficult to do review work as an 'outsider'.

You might be able to report an outright bug if you find one, and you can report "this old patch still applies and passes its tests", but other than that it seems difficult for the project to make use of what you say.

If you say "I read this patch and everything looks great, I'd love to see this in the next release", how much weight can the project put on that? How do they know whether you would have found problems if they were there?

Or if you read the patch and conclude "I can't find any actual bugs, but I'm pretty sure most of that code is going about things the wrong way, and I don't think this is going to get past a committer as it stands", how can you write that up in a way that's actually helpful?

(The last is where I ended up the one time I decided to have a go at reviewing a PostgreSQL patch. So I just said nothing and waited for an experienced reviewer to tell the author to rewrite it, which happened a month or three later.)

Contributing seems difficult when the issuetracker is an unstructured mailinglist

> Contributing seems difficult

yes, contributing is difficult

> an unstructured mailinglist

the main barrier to entry is not the lack of simple issue tracker though!

<rant>with something so well engineered, so visible each day to users (performance,features) and invisible to users (implementation), so portable (OS,arch) and so just .. careful.. The mental models needed to make meaningful changes to the code base, are so layered and detailed, the issue tracker is just as plain paper envelope as it can be ! If you dont know your bugs you shouldn't be here! so the gruff, take-no-prisoners engineering attitude goes .. and there is plenty of that in PostgreSQL, seems to me

On the other hand, modern FOSS plus dropping boomers, relays the actual fact that no, you do not have to get the "my patch was rejected by Tom" t-shirt to participate and IMPROVE the project. Its just that, this has not always been the culture, and now, maybe there are winds of change.

Every single core PG engineer today will pass away one day. PG is dead - long live PG ! yes, make the issue tracker but also, learn your bugs if you are seriously contributing at the core.

Actually it is. If you want people to help, make it easy to do so.

This means a structured list of what to do.

There’s a todo-wiki with some links to mailing threads of years old. With unaccepted patches without explanation what’s wrong.

If you want an engineer to help, don’t require him to be a PM

I would love to create another dialect of SQL where you could do:

1. FROM, 2. WHERE, 3. SELECT

Instead of

1. SELECT, 2. FROM, 3. WHERE

Leading with a description of what you'll "return" makes some sense, especially when you're chaining, nesting, or otherwise combining queries.

I agree that it's kinda weird, though. Every time I need to spend serious time in SQL I end up having to re-learn how to think "inside out", for that and other reasons.

From a parsing perspective, you can use the first keyword to branch to the proper parsing expression with ease...

e.g.: If the query starts with "SELECT" I can use the SELECT parser. If it starts with "UPDATE" I can use the UPDATE parser and so on.

With FROM/WHERE/SELECT you can no longer do that. So there's a cost... but to be honest, it's worth it in my opinion.

This is the exact format of LINQ statements in C#. Having the `select` later in the statement would be a productivity gain so that intellisense could be accurate the first time writing.

I really like timescale and time series data. How would I go about hiring or finding a cofounder who likes this stuff? Or hire a team familiar with it?

I would be more motivated if the project had begun making a transition to a less antiquated language.

It would amount to little more than a change to the build script, to change "gcc" to "g++", and then the project could immediately begin updating incrementally. New code could use all the modern conveniences.

The Gcc and Gdb projects both started this way sometime back, and it has been a stellar success. The common experience when preferring latest language features, whenever there is a choice, is that when the compiler is satisfied, the code is right.

I hoped Index Skip Scan for PostgreSQL become thing. Looks good it's now supported on TimescaleDB!

Reply on news.ycombinator.com