Stream: implementers
Topic: Tri-state or bi-state search logic for eq/ne
Keith Boone (Apr 13 2017 at 20:00):
I've been operating under the assumption that eq and ne in search use bi-state logic. If I ask for a resource that contains code X, and code is not present, obviously the resource will not be returned in either case. But when I ask for resources where code ne X, and code is NOT present, is the interpretation that I should or should not or should not return the resource. My original assumption was to return the resource if the query is code ne X and the resource does not have a value for code. However, given that we also have support for code:missing=false and code:missing=true, one might assume that tri-state logic rules are in effect. I would prefer not to assume that.
Lloyd McKenzie (Apr 13 2017 at 21:30):
My expectation would definitely be tri-state. However, a change request to have this clarified would be appropriate.
Grahame Grieve (Apr 15 2017 at 21:18):
my expectation is that it would not be tri-state. And my implementation is*not* (and I have the only implemnetation I know of). So clarification is definitely in order
Keith Boone (Apr 17 2017 at 14:25):
Clearly clarification is needed. Grahame, I too have an implementation that treats a resource missing a field as matching on the =ne criteria.
nicola (RIO/SS) (Apr 23 2017 at 05:35):
Here is how postgresql interprets NULLs and equality - https://www.postgresql.org/docs/9.6/static/functions-comparison.html
Chris Grenz (May 06 2017 at 10:45):
+1 for tri-state
Last updated: Apr 12 2022 at 19:14 UTC
