Chasing flavor-of-the-month seems like a pretty lost cause. I would like to see the patch in as well, but this seems like a pretty terrible reason for it.
PostgreSQL is the best open source relational database and I hope it remains that way.<p>While I don't mind seeing some non relational additions like JSON, it shouldn't be detrimental to Postgres relational core.<p>It's not a pissing contest : if MongoDB is more popular than Postgres for non relational (NoSql) data so what ?<p>It's not like Postgres is a commercial product and need wider adoption to keep the parent company afloat.
I am interested in it for another reason.<p>I am working on a not-yet-released (needs test cases!) CPAN module called PGObject::Type::JSON.[1] This module would let you effectively grab JSON types from the db, serialize and deserialize on the db query so you don't have to worry about it.<p>The serialization and deserialization is cool, but the question is what you can do with it. With the json functions if they become more functional, we could use JSON as an input to stored procedures, allowing arbitrarily complex data types to be fed into or out of stored procedures easily without having to serialize in tuple/array format.<p>A single, cannonical, well supported format would be huge in that it would allow you to do things with the database with extraordinary ease that are not trivial to do today. For example, really good json support + composite types as tuple elements (including arrays of composite types) + really good indexing support should give you an ability to approximate the power (for at least some workloads) of full custom type development, without needing to go to C.<p>[1] <a href="https://github.com/einhverfr/PGObject-Type-JSON" rel="nofollow">https://github.com/einhverfr/PGObject-Type-JSON</a>
I don't tkink people care so much for storing json, rather than "talk" json to the database. A different interface with simple insert and update with json is typically what people are after. A sort of ORM that simplifies inserts and update (and retrieval per primary key even) where data is provided as json would be a much better tool to attract the newer generation of programmers.<p>And like some of the comments said, PLEASE auto-partitionning!
I'd also add that SPA[1]/client-side applications are also an important consumer of databases with decent JSON support.<p>The "backend" for these types of applications are often relatively thin API wrappers around a database, with the bulk of application logic on the client-side.<p>Postgres' JSON improvements over the last couple of years have made it a pretty good choice already for these sorts of things, but the JSON indexing improving would make this a no-brainer.<p>[1] <a href="http://en.wikipedia.org/wiki/Single-page_application" rel="nofollow">http://en.wikipedia.org/wiki/Single-page_application</a>
Who cares about node.js? I am yet to see any Fortune 500 deployment on our consulting projects.<p>Following fashion usually doesn't lead to good results.
Postgres has never been popular. Why the sudden race for popularity now? MongoDB is replacing MySQL not Postgres. I would be interested to know what proportion of Postgres users use the JSON features, I suspect it is still small, even amongst the Node users. The popularity of Postgres is growing at a manageable rate, not an exploding rate and that seems fine to me.
I think this addition is extremely valuable, but courting node users is a weak argument for it. For me, it is more about the growing importance of semi-structured data, as well as other forms of data that are difficult to model outside of row-tuples and joins. Hstore was a hack...really useful, but a hack nonetheless. Hstore2 is a legitimate kv-store. Now if we could just do the same with a graph-store.
The linked post says : "I think we shouldn't release 9.4 unless it goes in."<p>I haven't been following the PG developers mailing list that closely recently and the article doesn't go into any details as to why it may be delayed.<p>From the link that @masklinn posted (Thanks, very interesting!) to a hstore presentation, it looks like the hstore side was developed by November last year, so I'm wondering why it wouldn't be ready for release by this September or whether its just the integration of hstore/JSON side of things that is the hold up.<p>For me, the new PG feature - although its an outside project - which I am most looking forward to in the 9.4 time frame is a newer JDBC driver for Postgres ( <a href="https://github.com/impossibl/pgjdbc-ng" rel="nofollow">https://github.com/impossibl/pgjdbc-ng</a> ).
I would like to suggest a modification to the author's thought about an ORM. What would be very cool would be a PG extension that wraps a mongodb compatible Api on top of postgresql.<p>That should completely short circuit the whole value proposition discussion of pg vs mongo.
Just by observing from the outside, Node.js and MongoDB, don't know what it is about those two platforms, but the communities formed around them seem to attract a large number of people I wouldn't want to interact with. There is a lot of immaturity and drama. Maybe it is the unreasonable and over-hyped marketing, not sure, can't quite put my figure on it.<p>Go is also a new language and framework that is popular but it has a different feel, a better one. Python so far, has one of the largest and most pleasant community (given its size) I've seen.<p>Json/KV friendly features are welcome, but perhaps looking to impress Node.js and MongoDB users is just barking at the wrong tree.