On Dec 5, 2012, at 10:04 AM, Andrew Dunstan <and...@dunslane.net> wrote:
> Indexing tree-like data isn't at all easy. We don't index XML either. There > has been discussion of this sort of indexing it in the past, and a couple of > people have said they would work on it, but I have not seen a proposal or a > single line of code. Yeah, I forgot that xmlpath was not indexable. > Jsonpath on its own would not do what you're suggesting. A first approach to > indexing treeish data requires that you generate all the possible paths and > index that. That would be quite explosive in volume. And anyway, jsonpath is > not on offer here. Yeah, explosive for sure, but for sufficiently small JSON values, that shouldn’t be much of an issue. I expect GINs to be expensive anyway (see full-text indexing). I am not invested in jsonpath; I just cited it as an example of using a single function call to do a nested search. Obviously `json_get(json, variadic text)` allows this, too, and could potentially use a GIN index of a JSON tree to perform the variadic text search at some point in the future, yes? > I'm sorry what I have offered isn't what you want, but plenty of other people > have told me it will go a long way meeting their needs. *Sigh.* I guess I have not been clear. The stuff you propose is *awesome*. I love it. The syntax with the chaining operators warms my heart, and I can’t wait to make *extensive* use of it in my procedural code. Maybe I would never *need* to do column queries of JSON contents often enough to require an expensive index. So I'm happy with this stuff, as long as it does not get in the way of supporting indexing at some point in the future. I can’t wait to start using it! Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
