On 12/05/2012 01:49 PM, Josh Berkus wrote:
*) xmlpath/jsonpath do searching (and decomposition) but are very
clunky from sql perspective and probably absolutely nogo in terms if
GIST/GIN. postgres spiritually wants to do things via operators and
we should (if possible) at least consider that first
Why is it a nogo for GiST? Ltree works, doesn't it? If we only support
equality lookups in what way is a JSON doc different from a collection
of ltree rows?
We'd probably want to use SP-GiST for better index size/performance, but
I don't see that this is impossible. Just some difficult code.
The set of paths for a single json datum can be huge, as opposed to one
for a single ltree datum. That strikes me as a serious barrier. In any
case, nobody I know of is even offering to do this - when they do we can
look at the design. Until then I'm assuming nothing.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
