This is nice, but it's a shame that after going to the trouble of writing a JSON parser in C and incorporating it into the main Postgres codebase, they didn't go one step further and add a json_project_key function that pulls values out of a JSON blob. That, combined with functional indices, allows you to store JSON blobs in your database and index on values inside them, or put another way, get the data model benefits of a NoSQL database [1] without sacrificing the mature Postgres internals.
The Heroku Postgres guys have been playing with this idea [2] using the PL/V8 plugin, which embeds Javascript as a supported language inside Postgres (and thus makes it trivial to implement the json_project_key function), but if Postgres is going to natively support JSON parsing then it shouldn't take an addon module to achieve this.
[1] Attempting to forestall the thread-jacking: I know NoSQL databases have other benefits besides their data model, but for some applications that's certainly one of the benefits.
[2] https://gist.github.com/1150804
Well. The parser is in the code now. The data type exists. So I assume it's possible to quite easily write a Postgres extension module that adds the missing pieces.
Reading from the linked article I would assume that they were kind of running out of time for the feature freeze.
I would expect the querying functions to be added in the release after this, or before in form of an extension.
On the other hand, as far as I can see XML support still does not allow for indexing or querying of the document itself, at least in core, even though it's been a postgres datatype for a long time.
This is typical for how Postgres adds features and functionalities. They tend to add a new core feature in one release, then add adjacent functionality and performance improvements in later releases.
I'm not on their core developer mailing lists, but I presume this is because of a prioritization of stability over most everything else.
It's also because Postgres work to internal release deadlines.
They'll take a stable half-feature over a buggy full-feature at any given deadline. What matters is that over time they patiently and carefully expand those half features.
The most visible example is the slowly increasing coverage of replication. This JSON feature is another example -- I expect it will grow in future into a fuller feature set.
Comments
This is nice, but it's a shame that after going to the trouble of writing a JSON parser in C and incorporating it into the main Postgres codebase, they didn't go one step further and add a json_project_key function that pulls values out of a JSON blob. That, combined with functional indices, allows you to store JSON blobs in your database and index on values inside them, or put another way, get the data model benefits of a NoSQL database [1] without sacrificing the mature Postgres internals.
The Heroku Postgres guys have been playing with this idea [2] using the PL/V8 plugin, which embeds Javascript as a supported language inside Postgres (and thus makes it trivial to implement the json_project_key function), but if Postgres is going to natively support JSON parsing then it shouldn't take an addon module to achieve this.
[1] Attempting to forestall the thread-jacking: I know NoSQL databases have other benefits besides their data model, but for some applications that's certainly one of the benefits. [2] https://gist.github.com/1150804
Well. The parser is in the code now. The data type exists. So I assume it's possible to quite easily write a Postgres extension module that adds the missing pieces.
Reading from the linked article I would assume that they were kind of running out of time for the feature freeze.
I would expect the querying functions to be added in the release after this, or before in form of an extension.
I can't help but think this is just step 1 in bringing native support for JSON indexing and querying.
On the other hand, as far as I can see XML support still does not allow for indexing or querying of the document itself, at least in core, even though it's been a postgres datatype for a long time.
I will donate money toward a json_project_key feature this way.
This is typical for how Postgres adds features and functionalities. They tend to add a new core feature in one release, then add adjacent functionality and performance improvements in later releases.
I'm not on their core developer mailing lists, but I presume this is because of a prioritization of stability over most everything else.
It's also because Postgres work to internal release deadlines.
They'll take a stable half-feature over a buggy full-feature at any given deadline. What matters is that over time they patiently and carefully expand those half features.
The most visible example is the slowly increasing coverage of replication. This JSON feature is another example -- I expect it will grow in future into a fuller feature set.
>get the data model benefits of a NoSQL database [1] without sacrificing the mature Postgres internals.
They already have that: http://www.postgresql.org/docs/9.1/static/hstore.html
HStore looks great, but as I understand it, it's just one level of key-value - JSON (and any document database) lets you store nested hashes.