Re: jsonb contains behaviour weirdness
| От | Peter Geoghegan | 
|---|---|
| Тема | Re: jsonb contains behaviour weirdness | 
| Дата | |
| Msg-id | CAM3SWZS5MTKQ=-zZypCwu6MB6SeZH8_YO3edzU6R=uSd9Cy-iA@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | jsonb contains behaviour weirdness (Alexander Korotkov <aekorotkov@gmail.com>) | 
| Ответы | 
                	
            		Re: jsonb contains behaviour weirdness
            		
            		 | 
		
| Список | pgsql-hackers | 
On Fri, Sep 12, 2014 at 6:40 AM, Alexander Korotkov <aekorotkov@gmail.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
В списке pgsql-hackers по дате отправления: