Category “Extensions” — 8 articles

In a recent article titled Inline Extensions we detailed the problem of how to distribute an extension’s package to a remote server without having access to its file system at all. The solution to that problem is non trivial, let’s say. But thanks to the awesome PostgreSQL Community we finaly have some practical ideas on how to address the problem as discussed on pgsql-hackers, our development mailing list. PostgreSQL is first an Awesome Community

We’ve been having the CREATE EXTENSION feature in PostgreSQL for a couple of releases now, so let’s talk about how to go from here. The first goal of the extension facility has been to allow for a clean dump and restore process of contrib modules. As such it’s been tailored to the needs of deploying files on the file system because there’s no escaping from that when you have to ship binary and executable files, those infamous .

PostgreSQL 9.1 includes proper extension support, as you might well know if you ever read this very blog here. Some hosting facilities are playing with PostgreSQL at big scale (hello Heroku!) and still meet with small caveats making their life uneasy. To be specific, only superusers are allowed to install C coded stored procedures, and that impacts a lot of very useful PostgreSQL extension: all those shiped in the contrib package are coded in C.

In the news recently stored procedures where used as an excuse for moving away logic from the database layer to application layer, and to migrate away from a powerful technology to a simpler one, now that there’s no logic anymore in the database. It’s not the way I would typically approach scaling problems, and apparently I’m not alone on the Stored Procedures camp. Did you read this nice blog post Mythbusters: Stored Procedures Edition already?

It’s this time of the year again, the main international PostgreSQL Conference is next week in Ottawa, Canada. If previous years are any indication, this will be great event where to meet with a lot of the members of your community. The core team will be there, developers will be there, and we will meet with users and their challenging use cases. This is a very good time to review both what you did in the project those last 12 months, and what you plan to do next year.

Dimitri Fontaine

PostgreSQL Major Contributor

Open Source Software Engineer