Wot no support contract?

It’s summer 2004, and I am considering which software platform we should use to host our new project, phuser.com. ‘ System Provisioning’ (a.k.a. ‘making it real’) of course covers many aspects, none of which I’m going to go into today.

One outcome of this was a choice of database. Social networking sites, even antidotes thereof, can’t get far without a database to power them. And so, to gloss over the whys and wherefores, it came to pass that I chose what claimed to be ‘The Most Advanced Open Source Database’. Happily the choice of PostgreSQL was founded on more than a strap-line, and in the intervening couple of years I have had every reason to be very satisfied with my original decision.

I look forward to writing more about that journey, but that too will have to wait. Today I’d like to relay one particular experience.

Firstly, I don’t want to turn this into an Open Source vs Proprietary debate. These are two-a-penny on any number of tech blogs you care to look at. Nevertheless, the issue of support has always been a reasonable concern for anyone considering Open solutions. At phuser.com we’re pretty hands on, so we deal with day-to-day issues ourselves. You learn a lot that way. But occasionally some assistance is needed. And so it was last weekend.

For the less technically inclined reader suffice it to say that there was a function in PostgreSQL which had changed between versions. You guys can jump to the <safe landing point>.

PostgreSQL generally has a high level of compliance with the SQL standard. There are some quirks though. One such quirk is the SET CONSTRAINTS command.

Up until v8.1, SET CONSTRAINTS did its stuff on all constraints that matched the name specified in the command. SQL says that ‘name’ must be schema qualified. The old way is actually very convenient for phuser, as it lets us change the mode on a particular type of constraint name defined in several schemas. phuser has many schemas. If we are not to be forever trapped in legacy land, we need to make some changes so that we can move to v8.2 at some point.

So, do I modify phuser by specifying every instance of the constraint in every schema, or is there a smarter way? (The answer to both these questions is yes, btw )

<safe landing point>

Rewind to last Sunday night. Midnight to be exact. I posted to the pgsql-sql mailing list wondering if there was a way to replicate the old behaviour of SET CONSTRAINTS.

I made my favourite hot milky beverage and went to bed.

6 hours later I woke up and went to work. New email. It’s from Tom Lane, one of seven PostgreSQL Core Devs. Not only has he said that it is sort-of possible, but he’s given me a code snippet:

for rec in
  select nspname
     from pg_namespace n join pg_constraint c on n.oid = c.connamespace
     where conname = $1 loop

     execute 'set constraints ' || quote_ident(rec.nspname) || '.'
        || quote_ident($1) || ' immediate';
end loop;

Nice one.

What tier of support licence would I need (and how much would I have to pay) to get direct personal response from a Core Dev at Oracle or IBM? On Sunday night.