PATCH: Add hstore_to_json()
in [PgSql]
|
From: Peter Eisentraut on 2 Jan 2010 20:04 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. Of course you could invent an API for JSON, but that doesn't mean it is necessary for a JSON type to exist, if you have PL/Perl and PL/Python as much better object-oriented APIs already available. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Hitoshi Harada on 2 Jan 2010 23:19 2010/1/3 Peter Eisentraut <peter_e(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 2 Jan 2010 23:31 Hitoshi Harada wrote: > A question: Isn't there no possibility that we have our own > implementation to handle JSON (i.e. no use of external libraries)? > > > Why should we reinvent a wheel someone else has already invented? This is what shared libraries are all about. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Hitoshi Harada on 3 Jan 2010 00:21 2010/1/3 Andrew Dunstan <andrew(a)dunslane.net>: > > > Hitoshi Harada wrote: >> >> A question: Isn't there no possibility that we have our own >> implementation to handle JSON (i.e. no use of external libraries)? >> >> >> > > Why should we reinvent a wheel someone else has already invented? This is > what shared libraries are all about. Because what we need may be another wheel nobody has already invented. I don't deny to use one of external libraries but don't like to decide specification by their specifications. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 3 Jan 2010 11:00
Hitoshi Harada wrote: > 2010/1/3 Andrew Dunstan <andrew(a)dunslane.net>: > >> Hitoshi Harada wrote: >> >>> A question: Isn't there no possibility that we have our own >>> implementation to handle JSON (i.e. no use of external libraries)? >>> >>> >>> >>> >> Why should we reinvent a wheel someone else has already invented? This is >> what shared libraries are all about. >> > Because what we need may be another wheel nobody has already invented. > I don't deny to use one of external libraries but don't like to decide > specification by their specifications. > > > OK, we really need to stop being abstract and say what operations we want. I think the minimal functionality I'd want is: convert record to JSON convert JSON to record extract a value, or set of values, from JSON composition of JSON Now all the libraries I have looked at (briefly) would require some code to provide for those, possibly quite a bit of code, but that doesn't mean we should just start from scratch and write our own JSON parser too. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |