Where are we on this?
---
Tom Lane wrote:
> Teodor Sigaev writes:
> >> We have an API definition by which extractQuery can distinguish "all
> >> match" from "no match". If we just legislate that "some match" isn't
> >> a v
Teodor Sigaev writes:
>> We have an API definition by which extractQuery can distinguish "all
>> match" from "no match". If we just legislate that "some match" isn't
>> a valid behavior for zero-key queries, then the code is correct and the
> Right now I don't see an example with zero keys and "
We have an API definition by which extractQuery can distinguish "all
match" from "no match". If we just legislate that "some match" isn't
a valid behavior for zero-key queries, then the code is correct and the
Right now I don't see an example with zero keys and "some match", consistent
method
On Wed, 2009-03-25 at 13:25 -0400, Tom Lane wrote:
> I am not sure whether the statement in 52.5 is still accurate, though.
> We have an API definition by which extractQuery can distinguish "all
> match" from "no match". If we just legislate that "some match" isn't
> a valid behavior for zero-key
Our fine manual sayeth (in section 52.5)
When extractQuery returns zero keys, GIN will emit an error. Depending
on the operator, a void query might match all, some, or none of the
indexed values (for example, every array contains the empty array, but
does not overlap the empty array), and
