2010/1/3 Peter Eisentraut <pete...@gmx.net>: > On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote: >> Mine for one :-). Quite apart from any other reason I would expect it to >> make indexing parts of the JSON more tractable. Say we use it to store a >> web session object, which is a natural enough use. I might well want to >> find or modify sessions with certain characteristics. I'm sure I >> wouldn't be the only possible usewr who would want something >> substantially more of such a type than just being able to validate it. >> We have XPath for XML. and a substantial accessor API for hstore, so why >> would we want anything less for JSON? > > Well, because they are not the same. XML is a tree structure (and the > XPath-SQL integration is already pretty weird), hstore is a set of > key/value pairs, JSON is, supposedly, an object, which doesn't map very > well to SQL. JSON is all of trees, object (key-value pairs), and arrays, which help denormalization of tables. Moreover, I think it's complementary to SQL because it doesn't map to SQL.
I don't think there are many operations that we need inside DB for JSON but at least indexing by gin is a typical case which means we need arbitrary "fetch" value operation from an object. And now that there are many server-side javascript like Node.js (http://nodejs.org/), storing, validating and direct output without converting from any other type is quite demanded feature of RDBM from web developer's view. A question: Isn't there no possibility that we have our own implementation to handle JSON (i.e. no use of external libraries)? Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
