From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: json accessors |
Date: | 2012-12-05 18:42:42 |
Message-ID: | FDA23402-7386-4B70-9D16-2707482A5A12@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 5, 2012, at 9:57 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Indexing large documents for fancy querying is a niche case but also
> quite complex. This isn't very well covered by xmlpath either btw --
> I think for inspiration we should be looking at hstore.
Agreed, although hstore, IIRC, does not support nesting.
> That said, how would you do that? The first thing that jumps into my
> mind is to cut right to the chase: Maybe the semantics could be
> defined so that implement hackstack @> needle would reasonable cover
> most cases.
Yes.
> So my takeaways are:
> *) decomposition != precise searching. andrew's api handles the
> former and stands on it's own merits.
Agreed.
> *) 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
I don't understand how xmlpath/jsonpath is not able to be implemented with operators.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-12-05 18:47:28 | Re: Dumping an Extension's Script |
Previous Message | Josh Berkus | 2012-12-05 18:41:29 | Re: ALTER TABLE ... NOREWRITE option |