JSON will be a core type in PostgreSQL 9.2 (opens in new tab)

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.

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.

>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

You might be interested in postgresql's hstore: http://www.postgresql.org/docs/9.0/static/hstore.html

It's a key-value store that allows querying, which is what I think you are lamenting in your comment. Here's a bit more about how to query and index with hstore: http://lwn.net/Articles/406385/. It's pretty simple and doesn't have anywhere near the number of querying possibilities that MongoDB has, but it can be used for on-the-fly column names (similar to JSON). You can only query on the root node's children, unlike the open-ended possibilities in NoSQL.

What would be interesting would be an extension to the SQL parser that supports JSONPath in SQL queries. like a WHERE JSON_COLUMN = some JSONPath query. Where it would act like a WHERE IN clause and could use a JSON style query syntax. I see no need to create a whole new construct when a valid one is available at this point. The two could be blended and it would create a very powerful way to query JSON data types in a relational system.

Look at PostgreSQL's hstore data type - that's pretty much what you're asking for.

Database-generated XML offers an excellent abstraction layer, allowing the business language to vary independently of the data format. (Swapping Java for C would require rewriting the entire XML construction code.) Coupling it to the database makes sense: swap rows for XML content. For example:

    SELECT xml_user_roster( 1 );

Given the extensive use of JSON in jQuery (Ajax) web applications, integrating JSON with PostgreSQL is smart. It allows the application code to vary independently of the business code that relies on JSON as a data interchange format.

That said, it would be great if JSON and XML were pluggable modules (similar to PL/R) that could be installed when needed.

I think you're missing the point. With this feature you'll be able to write a query that returns a JSON string of the results, possible as a field in a larger result set. It also validates that the JSON parses on the way in.

OT nitpick: SQLite.

> So, if you already have an environment where you are certain you are inserting valid JSON, it's not much different than just using the text type today.

Today, yes.

Tomorrow, when you launch an API and suddenly hundreds of different apps are talking to your systems, no.

Putting rich descriptions of data right next to the data is a good thing in the long run.