While on a 15 hour plane trip from LA to Sydney the other day I broke the back of making enums extensible, thus proving that there is some good to be had from both long plane flights and tiny netbooks.

I posted a work in progress patch on the -hackers list yesterday. In it current form, it will allow you to do these things:

• ALTER TYPE myenum ADD 'newlabel';


• ALTER TYPE myenum ADD 'newlabel' BEFORE 'existinglabel';


• ALTER TYPE myenum ADD 'newlabel' AFTER 'existinglabel';

The last one is not strictly necessary, and there is some opinion both for and against having it.

If labels are added at the end of the list (the first form does this) then, unless there is Oid wraparound, the enum Oids are in sorted order, which makes sorting and comparison operations very fast, as now. Labels added earlier in the list will sort and compare correctly, but not quite as fast.

Note that I have not provided for dropping existing labels, nor for changing the sort order of existing labels. The reason is that this would involve rewriting tables and indexes, where the current proposal will not require any such thing.

So, now it looks like Oracle's new business model for actually making money out of their investment in Sun is to become a patent troll. They seem to be going out of their way to make themselves pariahs in the Open Source world, as hated as SCO. Personally, I was always sceptical of their ability or intention to act well. They are simply not an organization that is geared to operating in this milieu. And there are plenty of people who should be at least a bit scared by this development, as Steven J Vaughan-Nichols points out.

I spent a year or two writing Java, and I get a bit impatient with people who like to rag on it. Their information is often out of date and ill-informed, in my experience. But anyone who now bases a major application, especially one which they sell, on Java would need to be very careful about how they proceed. And that involves a world of trouble and disputation. Surely it would be much simpler for any new project simply to say "OK, we'll use other technology, where there is less risk of running foul of patent lawsuits." That would be my reaction.

Incidentally, this is similar to the reasoning that led me to get involved with Postgres years ago. The company I was working for looked at shipping MySQL as a reference database with their product, and we were not interested in paying for a commercial license. Some people said we could, some said we couldn't. Our take was that we didn't want the hassle. Unless it was beyond dispute, we'd look elsewhere, and the next place we looked, naturally, was Postgres. By the time we decided against using Postgres, because there was then no Windows port, it was too late - I was hooked

There is a new release of the buildfarm client. There are no new features, but some cleanup and bug fixes.

The code can be downloaded from pgFoundry

Here are the release notes / change logs:

• Use git clean to remove build products left by vpath builds, following a suggestion from Robert Haas.
• provide for "default" entry in force_every setting
• Accomodate oddities in at least some versions of File::Copy
• If the web transaction fails, put back the old timestamps so the next run works on the same basis
• provide enough log to avoid server failure if we get an SCM error (bug found following report from Greg Sabino Mullane)
• work with older versions of git (bug found following report from Greg Sabino Mullane)

The cutover is due to happen soon,

Currently I have the following setup:

• On Fedora 6: a CVS mirror and a buildfarm animal, dungbeetle that uses it. This machine will retire some time in the next few months, and will probably be replaced by a machine running CentOS 6 when it is released.


• On Fedora 11, a mirror of my git repo that reflects the CVS state on github, and a buildfarm member quoll, that uses it. This is also where the github repo gets built.


• On Windows NT, another mirror of my github repo, and three buildfarm members, dawn_bat, red_bat and brown_bat, that use it

When CVS goes quiet, I will need to do the following:

• On all these machines, create mirrors of the new community repo, and cron jobs to keep them updated. The good news is that git is a whole lot more efficient about this than CVS is, so runs of "git fetch" won't place much stress on either then client or the server.


• Blow away all the per-branch repositories for all the buildfarm members, and change the config settings for 'scm', 'scmrepo' and 'scm_url'. The repo will point to the machine-local mirror. On dungbeetle, that means also removing the legacy 'cvsmethod' and 'cvsrepo' config settings.

I'll probably be doing this while I'm a long way from home, but with luck all will run smoothly.

When everything is settled down I will turn off my CVS mirrors.

Last Friday the CEO of Continuent sent out an apology for spamming the PostgreSQL community. Leaving aside the fact that the apology was issued on the postgresql-www mailing list, which is hardly the right forum, his apology left quite a number of questions unanswered. Many of those questions were subsequently asked explicitly by Robert Haas. So far there has been no response.

Also, it doesn't explain why I was spammed today, three days after the apology was issued.

Right now I'm thinking of putting Continuent on my automatic delete list.

I'm certainly not impressed by their technical expertise if they can't even get this right.

Australian IT News has picked up on my recent post about Oracle shutting down their buildfarm servers. It's good publicity for PostgreSQL but I doubt it will shame them into continuing to support us.

Meanwhile, EnterpriseDB through Dave Page have added some more Solaris members. Thanks, guys.

I don't really have a good title for this post, so I just thought I'd title it with one of my favourite Pink Floyd songs.

A few years ago, the author of Rails somewhat famously opined thus:

Active Record is opinionated software, just like the rest of Rails. This is a matter of opinion, not constraints. And the opinion goes as follows: I don't want my database to be clever! Keep those crayons firmly in place, please.

Unlike Christopher, I consider stored procedures and constraints vile and reckless destroyers of coherence. No, Mr. Database, you can not have my business logic. Your procedural ambitions will bear no fruit and you'll have to pry that logic from my dead, cold object-oriented hands.

I was reminded for the umpteenth time yesterday just how really, really silly this is. The only part of it that is spot on is the first clause, and I suspect that's because he didn't know that the actual meaning of the word opinionated is "unduly adhering to one's own opinion or to preconceived notions". Calling someone opinionated is not a compliment - it's an insult.

Here's what happened. Like a great many times before, a client sent me some stuff that was running very slowly and asked me how to speed it up. It was a piece of client side code that made some calls to the database to retrieve data and perform some checks on it and report on those by stashing the exception cases in a table to be later reviewed by the Data Quality team. It's a classic piece of business logic, and according to the dictum above does not belong inside the database. I rewrote it as a PL/pgSQL stored procedure. I didn't change the logic in any significant way. I simple stopped all that data being shipped out to a client to perform checks on it. The result was a reduction in execution time from the client's reported 6 minutes to 3 seconds.

This repeats a pattern I have seen hundreds or thousands of times. So here's my alternative dictum:

Let the database be good at what it's good at, including smart processing of bulk data. If you're lucky enough to be using PostgreSQL, you can implement the business logic in your favourite OO language (e.g. Ruby). Avoid shipping data to an external client program just to process and ship stuff back to the database. Only fetch data from the database if you need it to display or send to another system.

Or keep doing what you're doing, so people will continue to pay people like me to fix it

This weekend there will be a full pg_dump backup of the buildfarm database. After that I'm going to purge old log data (anything older than six months). Then we we're going to move it to PostgreSQL 8.4 as soon as possible - within a week I hope.

After that I hope to be able to implement Full Text Search on the logs.

The upgrade will involve some downtime, naturally. Buildfarm owners will be advised beforehand. But it shouldn't take too long to restore the 10Gb or less of data I am expecting.

I'm also planning for migrating my buildfarm animals to the new git repo when it comes online. I'll actually be travelling at that time, so I hope I can get it done without too much difficulty remotely. The one animal I have left building from CVS I will point at the git-cvs mirror. The remainder I will point directly at the public git repo initially. Later on I'll set up a local clone of the public repo and have them all pull from that. I hope that we don't have too many buildfarm members go quiet when CVS gets frozen.

At least one of my lessons from today is that the PostgreSQL JDBC driver now has support for COPY. I wonder how I missed that.

Three weeks ago, Oracle/Sun turned off five of the seven buildfarm members they had been running. Two weeks ago they turned off the other two. So they really do know how to play nicely in the open source community.

Luckily, there are other people who care about supporting PostgreSQL on Solaris / SPARC, and I'm happy that today we've registered two new buildfarm members for this platform. Thanks to Dave Page.

Some years ago I proposed that we should branch the source code tree much earlier than we have been doing. I didn't get much support at that time, but this year it was proposed again and we have in fact now done it, if not as early as I'd like, at least earlier than we have been in recent release cycles.

Apart from anything else that means buildfarm owners need to add REL9_0_STABLE to the list of branches they are now building. A few people have done that, but we need to add to the list. I have changed two of my regular buildfarm members, and will get the rest done today. It's important to get this coverage as quickly as possible as we run up to the release date for 9.0.

A couple of weeks ago, my old friend went into a supermarket in suburban Sydney, felt unwell, asked for an ambulance to be called, collapsed and died. He was a very sweet man, with a wicked sense of humor. He was a first class musician, with a wonderful voice, and also an excellent technologist - quite a renaissance man.

He was also one of my earliest contacts with the world of computing. I remember him taking me into the data centre of the Sydney Stock Exchange where he did some contract work in the middle 1970s, and explaining to me some of the physics of things such as fast tape drives and punched cards that I could see being used. It was to be another ten years or so before I got seriously involved with computing, but perhaps Clarke whetted my appetite a little.

Anyway, the world is a poorer and sadder place for his passing.

So the company that's all about "freedom to innovate" has a version of their flagship product called "Windows 7 Starter Edition" that is so restricted that you can't even change the desktop background with it. It's being sold on huge numbers of netbooks (see BestBuy's site, where they all seem to come with it.) For a version that's less braindead, you can pay another $70 or $100 on top of the $300 or so you paid for your netbook. Nice, eh? Members of my family, who mostly use nothing but Microsoft Operating Systems, and smile tolerantly at my use of Linux, are absolutely disgusted. Luckily for me, my netbook runs Linux (and because it doesn't have the usual restrictions Microsoft imposes on manufacturers, it has 2Gb of RAM rather than 1Gb, so I win both ways.)

Some people don't seem to get enumeration types. They think of them as C programmers tend to - as symbolic names for integer values.

But quiche eaters like me have quite a different point of view. Languages like Ada have had first class enumeration types for a long time (Ada is nearly 30 years old now). PostgreSQL's enum types are more of this kind, an ordered set of labels. Some people naïvely expect that underneath they will be stored as their ordinal position in the label set. In fact, for a technical reason, they are not. Rather, they are stored as globally (within the database) unique Oids. This is a bit counter-intuitive to some people, but really, it's just an implementation detail.

The biggest thing that bugs people about PostgreSQL's enums is that you can't extend them, i.e. you can't add more labels to the list. There is a workaround involving creating a new type, but it involves rewriting the tables that use them, which is unpleasant. Recently I have given some thought to that. I came up with scheme for a new enum type that would have been extensible. But as often happens, Tom Lane came up with a better idea. I've been working on fleshing that out, especially testing the possible performance impact, and I hope we can have something in 9.1. Being able to add labels to an enum set without table rewriting would make them much more usable.

D.Richard Hipp is the creator of SQLite. I met him at the speakers' dinner at SELinuxfest, attended his session on Saturday, and had a couple of conversations with him as well. He has a very friendly attitude to Postgres. He told me that whenever people ask him why he doesn't put more server class features into his product, he tells them that creating such a product has already been done, and it's called Postgres. In fact, he originally worked from Postgres documentation when he was creating SQLite.

Another thing he told me is that the large test suite he uses to test a number of databases besides his own crashes or gives incorrect results on every other database but one: Postgres.

SQLite is what I advise people to use when they want a simple embedded database. It also works well in my experience for small web sites. And its 'zero admin' nature makes it a good initial prototyping tool, too. I don't see it competing in the same space as Postgres, which has a very much richer set of features, scales better, and can handle much larger volumes of data. So to me we are not really competitors - we are more complementary than competing. I recently set up a very low volume web site for a fami;y member's business. SQLite worked well with the web framework software I was using and I was quite happy to use it.

Richard's talk was largely about the "new generation" databases. He doesn't like the term "NoSQL" much. He proposes instead that we call them "Postmodern Databases", in part because they have no notion of objective truth

Baron Schwartz of Percona had a somewhat different perspective, but many of his conclusions seemed to tend in the same direction. People should not lightly abandon the single server model of processing, he advised, and I think he's right.

I shuddered rather at Baron's description of MySQL's replication facilities, especially the lack of conflict detection and resolution. It reminded me a bit of David Sedaris' attitude to European style Christmases: "It's nothing I'd want for myself."

At the beginning of his session, he asked me if my presence indicated I was about to switch camps. I told him no, I was spying out the opposition Of course, we are all friendly, and not at daggers drawn.