It happens that you have to manage databases designed by your predecessor, and it even happens that the team used to not have a DBA. Those histerical raisins can lead to having a SQL_ASCII database. The horror!
What SQL_ASCII means, if you’re not already familiar with the consequences of such a choice, is that all the text and varchar data that you put in the database is accepted as-is. No checks.
So, after restoring a production dump with intermediate filtering, none of our sequences were set to the right value. I could have tried to review the process of filtering the dump here, but it’s a one-shot action and you know what that sometimes mean. With some pressure you don’t script enough of it and you just crawl more and more.
Still, I think how I solved it is worthy of a blog entry.
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]?
moment. Lots of attendees, lots of quality talks ( slides are online), good food, great party: all the ingredients were there!
It also was for me the occasion to first talk about this tool I’ve been working on for months, called pg_staging, which aims to empower those boring production backups to help maintaining staging environments (for your developers and testers).
All in all such events keep reminding me what it means exactly when we way that one of the greatest things about PostgreSQL is its community.
So there it is, at long last, the final 1.0.0 release of prefix! It’s on its way into the debian repository (targetting sid, in testing in 10 days) and available on pgfoundry to.
In order to make it clear that I intend to maintain this version, the number has 3 digits rather than 2… which is also what PostgreSQL users will expect.
The only last minute change is that you can now use the first version of the two following rather than the second one: