Archive for January, 2009
Who needs better email search for Thunderbird?
Thunderbird’s email search isn’t that great by today’s standards. If I type “red dog” into the search bar it doesn’t even tokenize and search for the words separately — it’s a substring match so “my dog is red” isn’t found. And it’s slow.
What about embedding “real” fulltext search into it? Sphinx perhaps?
Just a thought.
Idea: a reverse changelog for MySQL
Most software changelogs list what’s changed and what bugs are fixed during each upgrade. But when you’re evaluating an upgrade, what you’re typically concerned about is slightly different — it’s a combination of what’s changed and what might have broken. The fixed bugs aren’t as important for most people, who are either using a workaround or aren’t using the software. What people ask is “what do I have to change in my application, and/or make sure I’m not going to run afoul of, in order to use this new version?”
One of the interesting things about this is that you don’t know until sometime in the future, and it’s never a finished process. So as you look back from each new version, you have more information about the older versions. You see bugs that were fixed, and weren’t known when an older version was released, but which affected that version. So a “20/20 hindsight changelog” is going to be an evolving thing.
Such a changelog might say something like “when upgrading to 5.0.45, watch out for broken tmpdir handling; upgrade to at least 5.0.48 to avoid this bug.” Yes, this is necessarily a pessimistic look at the server, but people who are responsible for mission-critical server deployments are typically pretty conservative, and the good ones focus actively on identifying and managing risks. So it’s a good kind of pessimism.
PostgreSQL adds windowing functions and common table expressions
As Hubert writes, PostgreSQL 8.4 has windowing functions.
Well done. I’ve been watching progress on this for a while. It greatly enhances the expressiveness of SQL.
What about common table expressions (WITH and WITH RECURSIVE)? Yes, PostgreSQL 8.4 will have common table expressions (WITH and WITH RECURSIVE) as well. That’s the “other” quantum leap in the expressiveness of SQL in my mind.
Meanwhile I’m helping a client rewrite subqueries and finding bugs in MySQL’s subquery handling that cause equivalent expressions to return different results. Alas, nested-loop left-deep query plans made it easier for MySQL to have different storage engines, but hard for it to go beyond the basics of expressiveness in SQL. (Warning: uninformed opinion alert. Maybe I’m blaming the wrong thing.)
This post should not be regarded as MySQL bashing or PostgreSQL glorifying. Use the tool that works for you, standard disclaimers, etc etc.





