R-SET NOT_EQUAL
superhero · 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
Calculate the difference between Emil Blonsky's weight and Charles Chandler's weight.
the hint the set supplies: difference = SUBTRACT(SUM(weight_kg WHERE full_name = 'Emil Blonsky'), SUM(weight_kg WHERE full_name = 'Charles Chandler')); Emil Blonsky is the full name of superhero; Charles Chandler is the full name of superhero;
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: C the tool's rule, not the question's: the same number as int8 against numeric or float8 against numeric
int8 against numeric, one row, value 351
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.
The two statements name their result columns differently. A projection is compared by position and declared type, so these names did not decide the verdict. They are part of the canonical rendering each result is hashed under, so the two result hashes differ with them.
SELECT (SELECT weight_kg FROM superhero WHERE full_name LIKE 'Emil Blonsky') - (SELECT weight_kg FROM superhero WHERE full_name LIKE 'Charles Chandler') AS CALCULATEthis statement states no ordering of its own
sha256:c74ad330ad495db3a41b06646fc4eae7d87e57c80dd30b2f9a2ecc249be21a0d
SELECT (SUM(weight_kg) FILTER (WHERE full_name = 'Emil Blonsky') - SUM(weight_kg) FILTER (WHERE full_name = 'Charles Chandler')) AS weight_difference
FROM superherothis statement states no ordering of its own
sha256:29ca46571affb78bf5917272aea265cc06f6c2f197d92f1d2fec26e2743355b6
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, 1 row, up to 25 shown per side
| side | calculateint8 |
|---|---|
| gold | 351 |
from counterexample.json, 1 row, up to 25 shown per side
| side | weight_differencenumeric |
|---|---|
| second | 351 |
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, 1 row
| calculateint8 |
|---|
| 351 |
from counterexample.json, 1 row
| weight_differencenumeric |
|---|
| 351 |
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:c74ad330ad495db3a41b06646fc4eae7d87e57c80dd30b2f9a2ecc249be21a0d",
"baseline_result": {
"columns": [
{
"name": "calculate",
"declared_type": "int8"
}
],
"row_count": 1,
"truncated": false,
"rows_shown": 1,
"rows": [
[
{
"type": "int",
"value": 351
}
]
],
"result_hash": "sha256:c74ad330ad495db3a41b06646fc4eae7d87e57c80dd30b2f9a2ecc249be21a0d"
},
"planner_statistics": {
"superhero": {
"last_analyze": null,
"last_autoanalyze": "2026-09-08 05:19:12.518866+00",
"n_mod_since_analyze": 0
}
},
"shuffle": {
"seed": "1",
"row_limit": 300000,
"tables": [
"superhero"
],
"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:c74ad330ad495db3a41b06646fc4eae7d87e57c80dd30b2f9a2ecc249be21a0d",
"result": {
"columns": [
{
"name": "calculate",
"declared_type": "int8"
}
],
"row_count": 1,
"truncated": false,
"rows_shown": 1,
"rows": [
[
{
"type": "int",
"value": 351
}
]
],
"result_hash": "sha256:c74ad330ad495db3a41b06646fc4eae7d87e57c80dd30b2f9a2ecc249be21a0d"
}
},
"plan_variant": {
"run": false,
"reason": "the plan variant was not asked for"
}
}SELECT (SELECT weight_kg FROM superhero WHERE full_name LIKE 'Emil Blonsky') - (SELECT weight_kg FROM superhero WHERE full_name LIKE 'Charles Chandler') AS CALCULATEresult_hash sha256:c74ad330ad495db3a41b06646fc4eae7d87e57c80dd30b2f9a2ecc249be21a0d recomputed from this JSON: match
record_hash sha256:612ec14f1e61089389d48c4ee8c03da8d01753e3a82747d3d179a4e292102f17 recomputed from this JSON: match
from evidence-gold.json, 1 row
| calculateint8 |
|---|
| 351 |
SELECT (SUM(weight_kg) FILTER (WHERE full_name = 'Emil Blonsky') - SUM(weight_kg) FILTER (WHERE full_name = 'Charles Chandler')) AS weight_difference
FROM superheroresult_hash sha256:29ca46571affb78bf5917272aea265cc06f6c2f197d92f1d2fec26e2743355b6 recomputed from this JSON: match
record_hash sha256:2e0cf87ef17308e513c530b861d71d2d22601ad3cde8bdb1548d01f6918d3e2f recomputed from this JSON: match
from evidence-second.json, 1 row
| weight_differencenumeric |
|---|
| 351 |
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