Mike Stonebraker

And so I was associated with the commercial version of Ingress as well as I was still at the University of California as a professor.

So I got a call from an Ingress customer who said, you know, you implemented date and time wrong.

And I said, huh?

We implemented the Gregorian calendar and you can subtract.

And, you know, if it has, you know, days have 30 or 31 months except for February, except for leap years.

So subtraction on dates works exactly the way you would expect it to.

But he said, that's not what I want.

In his particular world, he said he was dealing with bond financial instruments.

And for some reason, I mean, you got the same amount of interest on his financial bonds during each month, no matter how long the month was.

So he had the date you bought the bond, the date you sold the bond.

He wanted to do a subtraction, multiply it by the coupon rate, and say that's the interest we paid you.

But, of course, his version of subtraction was March 15th minus February 15th is 30 days because that's the definition of his calendar.

And so he had to retrieve two dates out to user code, do the subtraction in user code, put the answer back, and it cost him a factor of two or three in efficiency.

And he said, why can't I just overload your definition of subtraction with what I want?

And of course, with Ingress, it was hard coded.

And the problem was, this is a case where you wanted bond time

just like you wanted points, lines, and polygons.

And so Postgres was engineered to have an extendable type system.

So you could have whatever data types you wanted and they were very efficient.

And that was the main gist of Postgres was that it had that flexibility.