From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why no jsonb_exists_path()? |
Date: | 2015-06-09 21:53:50 |
Message-ID: | 5577606E.6070603@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/09/2015 05:30 PM, Andrew Dunstan wrote:
>
> On 06/09/2015 02:40 PM, Tom Lane wrote:
>> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>> I'm noticing a feature gap for JSONB operators; we have no way to do
>>> this:
>>> jsonb_col ? ARRAY['key1','key2','key3']
>>> ... that is, there is no way for us to check for key existence in an
>>> indexable fashion. Given that @> already can check the whole path
>>> including the value, is there some challenge to stopping just short of
>>> the value I'm not seeing? Or is this just a "didn't get to it yet"
>>> issue?
>> Hm, well, the jsonb_path_ops opclass couldn't do it, because what it
>> indexes is hashes that include the value. I suppose jsonb_ops could
>> look for entries that match all of the keys and then see if the ordering
>> is correct.
>>
>>
>
>
> It looks to me like we'd need to index all paths in a document, or
> possibly hashes of all paths in a document. I don't think anything we
> have now will help much, unless my understanding is way off.
>
>
On second thought, yes, we could possibly check the index against the
path elements and then recheck.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2015-06-09 22:27:56 | pg_archivecleanup bug (invalid filename input) |
Previous Message | Andrew Dunstan | 2015-06-09 21:30:21 | Re: Why no jsonb_exists_path()? |