not futile?

Hint: They taste good.

I hope they start farming lobsters first. My favorite bug! Then crab, then shrimp... Mmm yummy bugs :D

...does that make the Moon Earth's toque?

Data might be the new oil, but the data of any one average person is worth almost exactly nothing. Should I charge Google almost exactly nothing for my data?

Yeah sure we can generate plenty of electricity. Just toss up another coal fired plant. Yay.

I'm thinking solar. If this technology, coupled with tracking solar concentrators, can be done more cost and radiation efficiently than current solar technologies, then it may be a huge win.

I stand corrected. And somewhat confused. I found the 6.5 release notes:

"Multi-version concurrency control(MVCC)

        This removes our old table-level locking, and replaces it with a locking system that is superior to most commercial database systems. In a traditional system, each row that is modified is locked until committed, preventing reads by other users. MVCC uses the natural multi-version nature of PostgreSQL to allow readers to continue reading consistent data during writer activity. Writers continue to use the compact pg_log transaction system. This is all performed without having to allocate a lock for every row like traditional database systems. So, basically, we no longer are restricted by simple table-level locking; we have something better than row-level locking."

That seems to imply that the "MV" existed, perhaps all along, but that the "CC" part was new in 6.5. Maybe that explains my confusion. Anyway, that was a long time ago. Thanks for whacking me with the clue stick :D

I never had to. But that's beside the point :)

There was always a latent threat of switching to MSSQL, for the exact reasons presented and debunked above. It could easily have happened, and I like to think I did a decent job of being about as ready for such a shift as possible.

As far as I know, Postgres has had MVCC from the start. I started dabbling in it at 6.4 (before it was enterprise ready IMO), and it certainly had it then.

MSSQL has also had a variant of MVCC since, um, 2005 I think. Can't be bothered to go look :)

I've had very few problems with Postgres that weren't actually a result of my own mistakes, and of course I handled them by fixing those mistakes. Any time I've actually needed to lean on someone else, the mailing lists have been very helpful, and very quick to respond. Not only that, but the mailing lists are frequented by the actual developers, so when you ask a question about some specific aspect of Postgres, there's a good chance you'll be answered by one of the people who actually built or at least maintains that piece of the code. As apposed to some clown reading from a script of trouble shooting bullshit who doesn't even know what language the software is written in. That, to me, is the very best kind of support there is.

How is any of that different with Postgres? Either way, you restore from back up and away you go. In neither case did blaming a software company get you out of trouble. That's why I say, it's a sham. You pay big money for something that, at the end of the day, isn't really worth a penny.

And the story of shifting liability is such a sham. Oracle isn't liable for anything. If you install Oracle and lose a bunch of data, you're still liable for it. And even if Oracle was liable, is that going to get your data back? No.

I wrote against Postgres for years and avoided stored procedures as much as possible for exactly the reason you describe; to avoid lock in. I never understood why so many people are perfectly happy to dive right into lockedinville. Avoiding lock in always served me and my company well.

This could also result in some really cool Street View footage.

Kim Jong Un: No, you idiots, I said we need to have a missile ERECTION! ERECTION! We should vote on what to do with them!