On Wed, May 7, 2014 at 1:39 PM, Tom Lane wrote:
> The indexscan is incorrectly returning rows where the queried key exists
> but isn't at top-level.
>
> We could fix this either by giving up on no-recheck for existence queries,
> or by changing the way that non-top-level keys get indexed. However
Peter Geoghegan writes:
> On Wed, May 7, 2014 at 1:47 PM, Tom Lane wrote:
>> No, wait, containment *doesn't* look into sub-objects:
>>
>> regression=# select * from j where f1 @> '{"foo": {"bar": "baz"}}';
>> f1
>> -
>> {"foo": {"bar": "baz"}}
>> (1 row)
>>
>> regression
On Wed, May 7, 2014 at 1:51 PM, Peter Geoghegan wrote:
> Yes it does. It's just not intended to work like that. You have to
> "give a path" to what you're looking for.
There is exactly one exception explicitly noted as such in the
user-visible docs, which is arrays and the containment of single
On Wed, May 7, 2014 at 1:47 PM, Tom Lane wrote:
> No, wait, containment *doesn't* look into sub-objects:
>
> regression=# select * from j where f1 @> '{"foo": {"bar": "baz"}}';
>f1
> -
> {"foo": {"bar": "baz"}}
> (1 row)
>
> regression=# select * from j where f
I wrote:
> Another idea would be to change the definition of the exists operator
> so that it *does* look into sub-objects. It seems rather random to me
> that containment looks into sub-objects but exists doesn't. However,
> possibly there are good reasons for the non-orthogonality.
No, wait, c
I wrote:
> The readability of that comment starts to go downhill with its use of
> "reset" to refer to what everything else calls a "recheck" flag, and in
> any case it's claiming that we *don't* need a recheck for exists (a
> statement I suspect to be false, but more later).
And, indeed, it's fal
