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.
After reading Simon’s blog post, I can’t help but try to give some details about what it is exactly that I’m working on. As he said, there are several aspects to extensions in PostgreSQL, it all begins here: Chapter 35. Extending SQL.
It’s possible, and mostly simple enough, to add your own code or behavior to PostgreSQL, so that it will use your code and your semantics while solving user queries.
In trying to help an extension debian packaging effort, I’ve once again proposed to handle it. That’s because I now begin to know how to do it, as you can see in my package overview page at debian QA facility. There’s a reason why I proposed myself here, it’s that yet another tool of mine is now to be found in debian, and should greatly help extension packaging there. You can already check for the postgresql-server-dev-all package page if you’re that impatient!
Yes. This pgloader project is still maintained and somewhat active. Development happens when I receive a complaint, either about a bug in existing code or a feature in yet-to-write code. If you have a bug to report, just send me an email!
So I had two bug reports about prefix in less than a week. It means several things, one of them is that my code is getting used in the wild, which is nice. The other side of the coin is that people do find bugs in there. This one is about the behavior of the btree opclass of the type prefix range. We cheat a lot there by simply having written one, because a range does not have a strict ordering: is [1-3] before of after [2-4]?