PostgreSQL 9.1 est dans les bacs ! Vous n’avez pas encore cette nouvelle version en production ? Pas encore évalué pourquoi vous devriez envisager de migrer à cette version ? Il existe beaucoup de bonnes raisons de passer à cette version, et peu de pièges. Nous commençons à lire des articles qui reprennent la nouvelle dans la presse française, et j’ai le plaisir de mentionner celui de programmez.com qui annonce « un système d’extensions inégalé ».
We still have this problem to solve with extensions and their packaging. How to best organize things so that your extension is compatible with before 9.1 and 9.1 and following releases of PostgreSQL? Well, I had to do it for the ip4r contribution, and I wanted the following to happen: dpkg-deb: building package `postgresql-8.3-ip4r' ... dpkg-deb: building package `postgresql-8.4-ip4r' ... dpkg-deb: building package `postgresql-9.0-ip4r' ... dpkg-deb: building package `postgresql-9.1-ip4r' ... And here’s a simple enough way to achieve that.
While Magnus is all about PG Conf EU already, you have to realize we’re just landed back from PG Con in Ottawa. My next stop in the annual conferences is CHAR 11, the Clustering, High Availability and Replication conference in Cambridge, 11-12 July. Yes, on the old continent this time. This year’s pgcon hot topics, for me, have been centered around a better grasp at SSI and DDL Triggers. Having those beasts in PostgreSQL would allow for auditing, finer privileges management and some more automated replication facilities.
While currently too busy at work to deliver much Open Source contributions, let’s debunk an old habit of PostgreSQL extension authors. It’s all down to copy pasting from contrib, and there’s no reason to continue doing $libdir this way ever since 7.4 days. Let’s take an example here, with the prefix extension. This one too will need some love, but is still behind on my spare time todo list, sorry about that.
If you’ve not been following closely you might have missed out on extensions integration. Well, Tom spent some time on the patches I’ve been preparing for the last 4 months. And not only did he commit most of the work but he also enhanced some parts of the code (better factoring) and basically finished it. At the previous developer meeting his advice was to avoid putting too much into the very first version of the patch for it to stand its chances of being integrated, and while in the review process more than one major PostgreSQL contributor expressed worries about the size of the patch and the number of features proposed.