R-SET NOT_EQUAL
card_games · mini_dev_postgresql from https://bird-bench.oss-cn-beijing.aliyuncs.com/minidev.zip (sha256 cc48ba16838204e4e214512030cb572eeb5f7bcdd999bae4b9b6ff12ec13b92f, downloaded 2026-09-07), member minidev/MINIDEV/mini_dev_postgresql.json
Which of these artists have designed a card in the set Coldsnap, Jeremy Jarvis, Aaron Miller or Chippy?
the hint the set supplies: card set Coldsnap refers to name = 'Coldsnap'; Jeremy Jarvis, Aaron Miller or Chippy are the name of artists which refers to artist IN ('Jeremy Jarvis', 'Aaron Miller','Chippy');
NOT_EQUAL states that these two statements disagree on this data under this rule. It does not state which of them is wrong.
read by hand, 2026-09-04: B harmless: one distinct row repeated; DISTINCT added by the prediction; a list under twice the answer with every row present
2 distinct artists, 5 rows, under three times the answer
a maintainer's reading of this question, out of classification.json, copied from plans/reports/prediction-mode-260904-real-predictions/classification.json. It is not a verdict and nothing above it was computed from it.
SELECT T1.artist FROM cards AS T1 INNER JOIN sets AS T2 ON T2.code = T1.setCode WHERE (T2.name = 'Coldsnap' AND T1.artist = 'Chippy') OR (T2.name = 'Coldsnap' AND T1.artist = 'Aaron Miller') OR (T2.name = 'Coldsnap' AND T1.artist = 'Jeremy Jarvis') GROUP BY T1.artistthis statement states no ordering of its own
sha256:f57f40683c63944be87f8676597378aab66bda7f622a040d922ba8396410ca78
SELECT artist
FROM cards
WHERE setcode = (SELECT code FROM sets WHERE name = 'Coldsnap')
AND artist IN ('Jeremy Jarvis', 'Aaron Miller','Chippy')this statement states no ordering of its own
sha256:ef851d2dd8cab5a28923f82c3d9cb0a185ca779d204d86e6140471efd33e52b5
The marked tokens are where the two texts differ. Two statements that differ everywhere can return the same rows, and two that differ in one token can return other rows; the verdict above is read off the results.
from counterexample.json, 0 rows, up to 25 shown per side
| side | artisttext |
|---|---|
| no rows |
from counterexample.json, 3 rows, up to 25 shown per side, 2 on this page
| side | times | artisttext |
|---|---|---|
| second | 2 | Jeremy Jarvis |
| second | 1 | Chippy |
set(second_rows) == set(gold_rows), float4/float8 cells as Python float as psycopg2 returns them, numeric as Decimal
https://github.com/bird-bench/mini_dev/blob/main/evaluation/evaluation_ex.py
result_eq: equal row counts and equal column counts, each row unordered as a quick rejection, then the two equal as a list when the gold text holds ORDER BY and as a multiset otherwise, under some permutation of the columns; DISTINCT is not stripped and re-executed, and the cells are PostgreSQL's as psycopg2 returns them
ruiqi-zhong/test-suite-sql-eval, exec_eval.py, result_eq, at commit 48cb78ec: https://github.com/ruiqi-zhong/test-suite-sql-eval/blob/48cb78ecf7f610620206283846c76751b18a1326/exec_eval.py
The class states what makes these two results unequal under this rule, read off the two results and nothing else. It does not state which of the two statements is wrong.
from counterexample.json, 2 rows
| artisttext |
|---|
| Chippy |
| Jeremy Jarvis |
from counterexample.json, 5 rows
| artisttext |
|---|
| Jeremy Jarvis |
| Jeremy Jarvis |
| Jeremy Jarvis |
| Chippy |
| Chippy |
A smell is a mechanical reason to read this gold statement again. It is a heuristic: it does not state that the statement is wrong, and a maintainer decides.
this statement orders by a text column holding only numbers, and ordering it as a number gives a different answer, so the gold may be sorting 9.5 above 10
the statement states no top level ORDER BY
{
"heuristic": true,
"reason": "the statement states no top level ORDER BY"
}this statement cuts its result at a LIMIT that does not decide which rows come back, so a different but equally correct statement can return other rows and score zero
the statement states no LIMIT
{
"heuristic": true,
"reason": "the statement states no LIMIT"
}rerun over the same rows in another physical order this statement gives another answer, so its result depends on how the rows are stored and not only on the data
{
"heuristic": true,
"rule": "R-SET",
"baseline_result_hash": "sha256:f57f40683c63944be87f8676597378aab66bda7f622a040d922ba8396410ca78",
"baseline_result": {
"columns": [
{
"name": "artist",
"declared_type": "text"
}
],
"row_count": 2,
"truncated": false,
"rows_shown": 2,
"rows": [
[
{
"type": "str",
"value": "Chippy"
}
],
[
{
"type": "str",
"value": "Jeremy Jarvis"
}
]
],
"result_hash": "sha256:f57f40683c63944be87f8676597378aab66bda7f622a040d922ba8396410ca78"
},
"planner_statistics": {
"cards": {
"last_analyze": null,
"last_autoanalyze": "2026-09-08 05:19:16.814042+00",
"n_mod_since_analyze": 0
},
"sets": {
"last_analyze": null,
"last_autoanalyze": "2026-09-08 05:19:52.284481+00",
"n_mod_since_analyze": 0
}
},
"shuffle": {
"seed": "1",
"row_limit": 300000,
"tables": [
"cards",
"sets"
],
"tables_not_shuffled": [],
"tables_skipped_for_size": {
"laptimes": 400524,
"legalities": 427907,
"posthistory": 303155,
"trans": 1056320,
"yearmonth": 383282
},
"tables_not_reached_by_a_copy": {}
},
"shuffled_copies": {
"run": true,
"verdict": "equal",
"differs": false,
"result_hash": "sha256:f57f40683c63944be87f8676597378aab66bda7f622a040d922ba8396410ca78",
"result": {
"columns": [
{
"name": "artist",
"declared_type": "text"
}
],
"row_count": 2,
"truncated": false,
"rows_shown": 2,
"rows": [
[
{
"type": "str",
"value": "Chippy"
}
],
[
{
"type": "str",
"value": "Jeremy Jarvis"
}
]
],
"result_hash": "sha256:f57f40683c63944be87f8676597378aab66bda7f622a040d922ba8396410ca78"
}
},
"plan_variant": {
"run": false,
"reason": "the plan variant was not asked for"
}
}SELECT T1.artist FROM cards AS T1 INNER JOIN sets AS T2 ON T2.code = T1.setCode WHERE (T2.name = 'Coldsnap' AND T1.artist = 'Chippy') OR (T2.name = 'Coldsnap' AND T1.artist = 'Aaron Miller') OR (T2.name = 'Coldsnap' AND T1.artist = 'Jeremy Jarvis') GROUP BY T1.artistresult_hash sha256:f57f40683c63944be87f8676597378aab66bda7f622a040d922ba8396410ca78 recomputed from this JSON: match
record_hash sha256:d04497c1eb9481a8120562bb8de95eba0aad09175e77faab6fc89e3f2b09ff8d recomputed from this JSON: match
from evidence-gold.json, 2 rows
| artisttext |
|---|
| Chippy |
| Jeremy Jarvis |
SELECT artist
FROM cards
WHERE setcode = (SELECT code FROM sets WHERE name = 'Coldsnap')
AND artist IN ('Jeremy Jarvis', 'Aaron Miller','Chippy')result_hash sha256:ef851d2dd8cab5a28923f82c3d9cb0a185ca779d204d86e6140471efd33e52b5 recomputed from this JSON: match
record_hash sha256:3c864248b32ba259f282e14714e68f3c768306cf776230186ca32dac064b96e7 recomputed from this JSON: match
from evidence-second.json, 5 rows
| artisttext |
|---|
| Jeremy Jarvis |
| Jeremy Jarvis |
| Jeremy Jarvis |
| Chippy |
| Chippy |
re-run this statement read-only against PostgreSQL 16.15 (Debian 16.15-1.pgdg13+2) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit | server=172.17.0.2/32:5432 | database=bird under the session settings and over the data this record's fixture digest names, and compare the two results under R-SET
re-run this statement read-only against PostgreSQL 16.15 (Debian 16.15-1.pgdg13+2) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit | server=172.17.0.2/32:5432 | database=bird under the session settings and over the data this record's fixture digest names, and compare the two results under R-SET