5 ms·

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.

wisty 13y ago
AJAX was flavour of the month in 2004. JSON has been flavour of the month since ~2006. While that makes it about 10 years younger than Postgres and MySQL, it's still not a flash in the pan.
- jeremyjh 13y ago
  You misunderstand me. I am not commenting on the nature of the feature, but rather the motivation cited in the SP for holding the release open to get it in. That reason could be summarized as "node.js and mongo!!".
nousernamesleft 13y ago
Not only is chasing fads a waste of time, but his perception of node is frankly rather bizarre. The node fad is already over. It isn't gaining steam. Mongo is on its way out, it is the mysql of the nosql world and everyone realizes it now. Holding back a release that contains real functionality because of a delay in a feature that won't win over node people anyways is just insane.
rosser 13y ago
Because following the latest fashions is clearly the PostgreSQL Core Committee's raison d'être...
crucialfelix 13y ago
Its not flavor-of-the-month, its flavor-of-the-generation. That's a 4 or 5 year span- not a ship you want to miss. Django and Rails have brought significant Postgres adoption. If widespread OS adoption and support is a goal then it is wise to pay attention to the features and platforms that will drive adoption.
- jeremyjh 13y ago
  MongoDB is "flavor-of-the-generation" ? If so, then that generation is truly lost.
  - crucialfelix 13y ago
    no, Django and Rails have been a generation. Node.js and Go are potentially the incoming generation (according to the article) Node has encouraged MongoDB usage because there were nice packages that made working with Mongo very easy. If Postgres supports JSON with powerful features then developers will make npm packages that support it and this will make Postgres very attractive.
  - ebiester 13y ago
    Inexpensively replicating key-value databases for suitable problems is the "flavor-of-the-generation."
spikels 13y ago
I disagree. Node and MongoDb have both had very strong growth for several years now across a wide variety of users from individual hackers to the largest companies. While I'm skeptical of MongoDb's long term prospects due to its underlying technology and tight sponsorship I can understand the appeal of it's ease of use, especially for development. Node and JavaScript, on the other hand, seem clearly here to stay. While far from perfect are becoming deeply embedded in many key areas. And even if you don't like MongoDb or Node, JSON is clearly one of the most popular data formats - better support is surely a good thing.
jeffdavis 13y ago
I agree in the sense that nobody should re-architect their product around a trend. But this is different because the postgres architecture is very much capable of great support here, and getting even better. Postgres has the best support for adding in new types, with amazing capabilities around indexing. I'm not just talking about different kinds of BTrees, I mean real non-scalar indexing strategies like inverted indexes (used for full text, but also great for JSON), similarity matching indexes, unbalanced indexes, spatial indexes, etc. The author merely wants to use this infrastructure as intended for the JSON use case. Easier said than done, of course, but no architectural compromises need to be made in the process of providing this support.

wisty 13y ago

AJAX was flavour of the month in 2004. JSON has been flavour of the month since ~2006. While that makes it about 10 years younger than Postgres and MySQL, it's still not a flash in the pan.

jeremyjh 13y ago
You misunderstand me. I am not commenting on the nature of the feature, but rather the motivation cited in the SP for holding the release open to get it in. That reason could be summarized as "node.js and mongo!!".

nousernamesleft 13y ago

Not only is chasing fads a waste of time, but his perception of node is frankly rather bizarre. The node fad is already over. It isn't gaining steam. Mongo is on its way out, it is the mysql of the nosql world and everyone realizes it now. Holding back a release that contains real functionality because of a delay in a feature that won't win over node people anyways is just insane.

rosser 13y ago

Because following the latest fashions is clearly the PostgreSQL Core Committee's raison d'être...

crucialfelix 13y ago

Its not flavor-of-the-month, its flavor-of-the-generation. That's a 4 or 5 year span- not a ship you want to miss. Django and Rails have brought significant Postgres adoption. If widespread OS adoption and support is a goal then it is wise to pay attention to the features and platforms that will drive adoption.

jeremyjh 13y ago
MongoDB is "flavor-of-the-generation" ? If so, then that generation is truly lost.
- crucialfelix 13y ago
  no, Django and Rails have been a generation. Node.js and Go are potentially the incoming generation (according to the article) Node has encouraged MongoDB usage because there were nice packages that made working with Mongo very easy. If Postgres supports JSON with powerful features then developers will make npm packages that support it and this will make Postgres very attractive.
- ebiester 13y ago
  Inexpensively replicating key-value databases for suitable problems is the "flavor-of-the-generation."

spikels 13y ago

I disagree. Node and MongoDb have both had very strong growth for several years now across a wide variety of users from individual hackers to the largest companies. While I'm skeptical of MongoDb's long term prospects due to its underlying technology and tight sponsorship I can understand the appeal of it's ease of use, especially for development. Node and JavaScript, on the other hand, seem clearly here to stay. While far from perfect are becoming deeply embedded in many key areas. And even if you don't like MongoDb or Node, JSON is clearly one of the most popular data formats - better support is surely a good thing.

jeffdavis 13y ago

I agree in the sense that nobody should re-architect their product around a trend. But this is different because the postgres architecture is very much capable of great support here, and getting even better. Postgres has the best support for adding in new types, with amazing capabilities around indexing. I'm not just talking about different kinds of BTrees, I mean real non-scalar indexing strategies like inverted indexes (used for full text, but also great for JSON), similarity matching indexes, unbalanced indexes, spatial indexes, etc. The author merely wants to use this infrastructure as intended for the JSON use case. Easier said than done, of course, but no architectural compromises need to be made in the process of providing this support.