> we'd be in a much better place what code-archaeology is concerned.

This sounds like a great setup for a sci-fi novel. 500 years into the future, the infrastructure their distant ancestors coded has begun to fail. Now Biff Miffington, code-archaeologist, must sift through millions of forgotten messages using a mysterious tool remembered only as "git." Its interface is arcane and the remaining messages broken, tainted by the destructive influence of Mountain Dew and Cheetos. Will he unravel the mystery that's causing Candy Crush Saga MCCXXXI to kill its users?

Edit: On what OP actually said, I'd also like to say that Postgres is an awesome product.

Vernor Vinge's A Deepness in the Sky actually has a role described as "programmer archaeologist":

http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstel...

That is, btw, an absolutely fantastic distant future sci-fi novel. Among the best of all time. (Vinge doesn't consistently product books that good, but man that one is great.)

Just bought it because that premise sounds amazing. Amazon has it listed as "Zones of Thought series Book 2". Should I read book 1 before reading this?

Maybe, but I don't think you necessarily need to. I started with A Deepness in the Sky and then read the other two (and then all the other books Vinge has written).

Especially since it is actually a prequel, I don't think the order is that important.

There are things in Deepness that will have more significance if you've read A Fire upon the Deep, but nothing central to the plot. They're both standalone novels, just in the same setting/universe/background.

A great book, full of interesting ideas and implications of software development carried on over millennia.

Testing the waters, I'd played with the idea of a story with basically this setup:

Two new developers start at a company/startup, and are brought in to do a six-month sprint to fix a stalled/broken product after the development team becomes unavailable because reasons. So, they're dropped into a codebase and are trying to pull everything together.

However, as they work through into deeper and deeper parts of the system, the commit messages and comments get more and more cryptic and unsettling, hinting at the reasons for the prior team's dissolution, the business forces that caused that to happen, and maybe something worse/better going on outside.

I'm really lazy though. :(

>after the development team becomes unavailable because reasons.

Every member of the programming team was attacked and killed by wolves in unrelated incidents on the same night.

And they said it couldn't happen...

I like it. It reminds me of something like System Shock (2 is the one I played), where you learn about what happened on this ship before it was overrun by mutants from journals and such. Instead of a book, this may work well as a game of some sort. Perhaps even text-based?

This is a really good idea. Too bad I seriously suck at writing fiction or I'd pick this up.

In Vernor Vinge's Deepness In The Sky, there really are code archeologists, as it's often simpler to find programs than to write them from scratch.

They believe that the Unix epoch (since extended many times over) dates to the moon landing (approximately correct), since the exact historical explanation has been lost.

When I say "code archeology", I mean the equivalent of "git blame" without assigning blame - just finding out why stuff is the way it is and not who's responsible because that would be totally pointless, especially years after the incident.

I do like your spin however :-)

Oh yeah, I knew your meaning. Doing blame and bisect to find a deep-seated bug can be a lot of fun... or frustrating and miserable. I tend to give terrible on word commit messages when I'm developing, but I always do an interactive rebase to clean things up and make a reasonable view of history. We use Phabricator a lot too, which does a great job of letting you annotate code, commits etc.

Praise is a built-in alias for SVN, not so for git unfortunately.

Ditto in Bazaar, which copied SVN. But there's an easy fix:

  git config --global alias.praise blame

Ken Macleod's books have a some of this kind of stuff in them - people having to maintain old space stations that run Oracle DB's and stuff like that.

Candy Crush Saga on git? Sounds more like a fantasy novel.

Heh, the twist is that he discovers the secret, which is that Candy Crush is really a giant conspiracy to cull the feeble. He decides not to fix anything.

Maybe not once it becomes an ancient relic: https://github.com/Olde-Skuul/doom3do

I'm pretty sure Sony has already optioned this plot and trying to get Tom Cruise for Biff.

In addition to those peripheral benefits there's also the intangibles. Mainly that worrying about database stability is just not part of my life the way it was five years ago before I'd fully migrated to PostgreSQL.

well said @pilif. I've been using PostgreSQL since the early 6.x days as the back end to web sites. As time went on, I developed an Accounting & ERP software suite in C++ with a thin wrapper around libpq. We've pretty much standardized on PostgreSQL for the things you just said: "friendly community, awesome documentation, awesome tools, and of course and awesome product...."

I literally have a multi-million dollar business & product because of it. And without it, we would be stuck with Oracle or MS-SQL.

And we just recently added full text search within our product using the PostgreSQL full text add-on. My customers absolutely love the feature and they love us because of this.

Another HUGE Thank you from me too.

+1 for #postgresql help. Recently I had a really weird problem, and after a few hours with forums and manuals I went there to ask for help. They saved me I don't know how many more hours that would almost for sure not found the completely unexpected answer. Thanks!

Can the documentation or user experience be improved to prevent that issue from happening to someone else?

There isn't an easy way imho, because this was a real edge case caused by creating a new index while there was an "idle in transaction" connection: http://dba.stackexchange.com/questions/84844/dropped-an-inde...

But more in general, at least in my experience, understanding and optimizing indexes usage is the most important and most difficult task with postgresql, and improving the documentation about this could really help. Usually they work well on their own, but a few times I was really baffled why pg wouldn't use an index which I created to optimize some important and slow query, even if using the index (when I found a way to "convince" pg to do so) cut the execution time by a factor of 100 or even 1000.

The easiest improvement that comes to my mind would be to add to the manual a better and more in-depth explanation about how to optimize index usage; this could include a FAQ where you could also include my edge case. This current page could be a starting point: http://www.postgresql.org/docs/9.3/interactive/indexes-exami...

An even better but much more long term project would be to improve the EXPLAIN ANALYZE commands; specifically it would be great if it could show the different plans considered, making it easy to understand why a specific plan was discarded. Right now, the only way to nudge pg in the right direction is by trial and error. Also making the explain output easier to understand would help, but I guess that's difficult.

Anyway, thanks again for all the effort of the pg contributors!

>even new contributors are not really required to have a thick skin nor flame retardant suits

I will have to look into this community more. I've been burned by some oss communities before.

Since you're planning on doing some conceptual work with JSONB, just a heads upon one gotcha -

duplicate properties are not allowed. I.E.:

{ task: "do stuff", task: "do other stuff" }

which sometimes is useful when you have front-end data with an N-number of entries but its a form that serializes to an object instead of an array. There are other use cases too.

RFC4627 §2.2 ¶1

> The names within an object SHOULD be unique.

RFC2119 §3

> [SHOULD], or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Not allowing duplicate keys in JSON objects is very close the exact opposite of a gotcha. Allowing and round-tripping them would be a gotcha.

No, it can be a gotcha because the json column type (which still exists and many may mistakenly use instead of the jsonb type) allows it:

select '{"foo": 1, "foo": 2}'::json; json ---------------------- {"foo": 1, "foo": 2} (1 row)

select '{"foo": 1, "foo": 2}'::jsonb; jsonb ------------ {"foo": 2} (1 row)

So technically, the gotcha is you have to remember to use jsonb instead of json, as well as json having a true "gotcha" and jsonb not having one.

the json type just stores the string value passed to it, but only the final value is available to the JSON-aware operators.

  mydb=# select
      ('{"foo": 1, "foo": 2}'::jsonb)->'foo' jsonb_foo,
      ('{"foo": 1, "foo": 2}'::json)->'foo'  json_foo;
  jsonb_foo|2
  json_foo|2

Most implementations that allow them, from those I've seen only take the last (in actual order) value...

I would have been worried if it was allowed. This is exactly what arrays are for.

Okay, I'll bite.

What, exactly, do you think should happen if you have an object of the form

    { task: "do stuff", task: "do other stuff" }

? Objects in JSON are key-value pairs. A single key goes to a single value. Instead, you should map task to an array of values.

Um, I think you're agreeing. "Instead, you [i.e., not the deserializer] should map task to an array of values."