On Mon, Dec 12, 2011 at 7:37 PM, Daniel Farina <dan...@heroku.com> wrote: > On Mon, Dec 12, 2011 at 4:51 PM, Peter van Hardenberg <p...@pvh.ca> wrote:> >> PL/V8 is fast, it's sandboxed, and while it doesn't provide GIN or >> GIST operators out of the box, maybe those could be motivated by its >> inclusion. > > I also feel that a big problem with JSON as a data type is that there > is not a powerful, common navigation method. JSON path is basically > pretty obscure by comparison to XPath. As a result, the common > approach to navigation in a JSON structure is basically "write > procedures". And that is only perfectly supported by a full-blown > interpreter.
This. For me, postgres xml extensions is 'a whole bunch of extra stuff that comes with the xpath function'. How you get data into and out of json is much more interesting than how the type is set up internally or how it's parsed. There must be some way to avoid iterative set up and tear down of json objects (maybe as a cast?) -- postgres arrays of composites can set up data in a way that feels very much like json in it's construction. One big reason why people might go to server side json is to try and avoid tedious marshaling of data between client and server. The xpath function has had its warts, but it offers very tight coupling between your database and your documents. In the case of json, I think you can go even further. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers