Review of Patch Reviewing Wednesday 16:20 Berlin
Twitter: @net_snow LinkedIn: stephen-frost Company website: crunchydata.com Company Blog: info.crunchydata.com/blog
I am the Chief Technology Officer for Crunchy Data, a PostgreSQL Committer, Major Contributor, Member of the PostgreSQL Infrastructure Team, on the board of the United States PostgreSQL Association, on the board of Software in the Public Interest, have been the PostgreSQL organization administrator for GSOC the past couple of years and now am co-organizer for our first Google Code-In effort. I’ve worked with PostgreSQL for about 15 years now, spending time on various security aspects of PostgreSQL (the role system, the GRANT system, column level privileges, row level security), and a few other items here and there.
I’m heavily on the PostgreSQL mailing lists, the #postgresql channel on Freenode, the “postgresteam” slack, speaking at PGConf.EU, PostgresOpen, PGCon, FOSDEM PGDay, PGConf.BR, SCALE, and other PostgreSQL Community Conferences.
Yes, I’ve been to many of the PGConf.EU conferences (Dublin, Amsterdam, Warsaw, Vienna, Tallin) and have helped out at the PostgreSQL booth and events at FOSDEM the past few years. I’m often speaking or at least helping out at the event, usually not hard to find!
This talk is about reviewing patches which have been proposed for inclusion in PostgreSQL. We’ll talk about the process a patch takes from being submitted to the hackers mailing list, being registered in the commitfest application, what to do after pulling down the patch and building PostgreSQL with it, what to look for when it comes to doing a review of patch, from the functional portions through to how to review the code itself.
This talk is well suited for anyone interested in helping move PostgreSQL forward.
Knowing how to work with patches, git, and how to build PostgreSQL are really the particularly important things to know ahead of the talk, and much of this can be found by visiting the PostgreSQL wiki, particularly the Developer FAQ.
I’m a big fan of the new default roles (though that was my patch, so perhaps that doesn’t count) and the new “fast new column with a default value” feature. What would be really neat to see is a way to extend that concept to work more generally than just when a column is added to a table but also to be able to have default values for columns that already exist- and eliminate storing that data redundantly when we go to do a new insert!
I would say High Performance pgBackRest, but apparently that’s been scheduled at the same time as my talk! Instead, I’ll be going to at least Peter Geoghegan’s talk about bloat, and Magnus’ talk about What’s new in PostgreSQL 11.