From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb contains behaviour weirdness |
Date: | 2014-09-12 17:41:24 |
Message-ID: | CAM3SWZS5MTKQ=-zZypCwu6MB6SeZH8_YO3edzU6R=uSd9Cy-iA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov
<aekorotkov(at)gmail(dot)com> wrote:
> Even more weird :)
Agreed.
> The reason why jsonb contains behaves so is check in the beginning of
> jsonb_contains. It makes fast check of jsonb type and elements count before
> calling JsonbDeepContains.
>
> if (JB_ROOT_COUNT(val) < JB_ROOT_COUNT(tmpl) ||
> JB_ROOT_IS_OBJECT(val) != JB_ROOT_IS_OBJECT(tmpl))
> PG_RETURN_BOOL(false);
>
> It's likely that "JB_ROOT_COUNT(val) < JB_ROOT_COUNT(tmpl)" should be
> checked only for objects, not arrays. Also, should JsonbDeepContains does
> same fast check when it deals with nested objects?
I think this is due to commit 364ddc. That removed the extra step that
had arrays sorted (and then de-duped) ahead of time, which made arrays
behave like objects at the top level. I think that this sort + de-dup
step was mischaracterized as purely a performance thing (possibly by
me). Basically, JsonbDeepContains() is consistent with the previous
behavior at the top level, but not the current (inadvertently altered)
behavior. I think the fix is probably a return to the previous
behavior. I'll take a closer look.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-12 17:41:30 | Re: [v9.5] Custom Plan API |
Previous Message | Gregory Smith | 2014-09-12 17:39:10 | Re: Scaling shared buffer eviction |