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.
Let’s say you need to ALTER TABLE foo ALTER COLUMN bar TYPE bigint;, and PostgreSQL is helpfully telling you that no you can’t because such and such views depend on the column. The basic way to deal with that is to copy paste from the error message the names of the views involved, then prepare a script wherein you first DROP VIEW then ALTER TABLE and finally CREATE VIEW again, all in the same transaction.
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.
I’ve been working on skytools3 packaging lately. I’ve been pushing quite a lot of work into it, in order to have exactly what I needed out of the box, after some 3 years of production and experiences with the products. Plural, yes, because even if pgbouncer and plproxy are siblings to the projets (same developers team, separate life cycle and releases), then skytools still includes several sub-projects.
Here’s what the skytools3 packaging is going to look like:
If you don’t remember about what pg_staging is all about, it’s a central console from where to control all your PostgreSQL databases. Typically you use it to manage your development and pre-production setup, where developers ask you pretty often to install them some newer dump from the production, and you want that operation streamlined and easy.
Usage The typical session would be something like this:
pg_staging> databases foodb.dev foodb foodb_20100824 :5432 foodb_20100209 foodb_20100209 :5432 foodb_20100824 foodb_20100824 :5432 pgbouncer pgbouncer :6432 postgres postgres :5432 pg_staging> dbsizes foodb.