A report may ask for records that do not appear in an exclusion list. That sounds straightforward until the comparison contains missing identifiers. The database then evaluates the expression’s documented rules, which may differ from the business owner’s informal assumption that every unmatched-looking record is definitely outside the list.
Separate proven non-membership from an unresolved comparison caused by missing values. The reporting review should establish the intended treatment of each case before accepting an empty result or a changed population as a correct business answer.
Describe what exclusion is intended to mean
Consider a hypothetical operations report that lists service requests not present in a separately maintained hold list. The owner should define what makes a hold-list entry identify a request and what happens when an entry lacks that identifier. An incomplete list entry may require correction or review rather than an automatic conclusion about every other request.
Also identify how the report handles a request whose own comparison identifier is missing. That is different from a known request identifier that does not match a complete hold list. The worksheet should preserve both cases instead of hiding them behind one convenient included or excluded flag. For example, keep an incomplete hold entry visible as an input-quality finding while separately explaining the selection result; correcting that entry and changing the query are different proposed actions.
Read the comparison’s missing-value rule
PostgreSQL 18’s subquery documentation explains that NOT IN can return null rather than true when no equal right-hand value exists but a right-hand row is null. It also documents null behavior for a null left-hand expression. These are scoped expression rules, not a universal business policy for incomplete lists.
The implementer should explain how the actual report treats the result of that expression. A result that is not true is not affirmative evidence that the request was found on the hold list. Keep the database expression’s outcome separate from the business explanation assigned to it, particularly when the interface presents only a final list without the underlying uncertainty.
Include incomplete comparisons in acceptance examples
The following proposed worksheet asks for expected business outcomes without prescribing replacement SQL. It is not a policy recommendation for customer permissions or any regulated decision.
| Comparison case | Question for the report owner | Evidence to inspect |
|---|---|---|
| Known identifier matches | Is this a confirmed exclusion? | Matching source entry |
| Known identifier does not match a complete list | Should the request be included? | Complete comparison context |
| List contains a missing identifier | What uncertainty does that create? | The actual expression result |
| Request identifier is missing | Is comparison meaningful yet? | An explicit incomplete-record decision |
| List is genuinely empty | What should no entries mean? | The approved empty-list rule |
The review should not conflate an empty list with a list containing an incomplete entry. Their business meaning and expression behavior should be examined separately in the proposed implementation.
Investigate a changed population before labeling it
In the hypothetical service report, adding an incomplete hold-list entry may change the report’s behavior. Ask the implementer to show the relevant input, the comparison outcome, and the final selection. Do not assume that every omitted request must have become a confirmed hold or that the database has lost its source record.
If the team decides to correct incomplete entries or apply a different comparison design, preserve the approved missing-value policy and test the actual implementation against it. The article does not recommend silently removing inconvenient list rows, treating unknown cases as eligible, or changing the business definition simply to make the output look plausible.
Compare OceanBase through the approved selection rule
OceanBase Database can be evaluated for operational records and associated MySQL- or Oracle-oriented reporting workloads. Its compatibility positioning does not establish that a source report’s missing-value assumptions are correct or that every expression maps identically in the chosen mode and version.
Retained MySQL, PostgreSQL, and an OceanBase proposal should use the same complete and incomplete comparison cases. Ask each implementation to explain both selected records and unresolved outcomes. A successful query or a smaller output does not establish that the intended exclusion policy has been preserved.
Accept a selection that can explain uncertainty
A bounded proposed review should identify the comparison key, incomplete-entry treatment, actual expression behavior, and expected report population. No queries, list corrections, or customer decisions have been executed for this article. Its examples are hypothetical acceptance situations.
This task differs from choosing how to store an empty field or counting non-null values. It concerns what a negative membership condition establishes when the evidence is incomplete. Making that distinction visible gives buyers a clearer reporting acceptance question than assuming that every record absent from the output was positively matched to an exclusion.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.