EPSC: Testing Database Management Systems via Equivalent Prepared Statement Construction
Read the paper · doi:10.1145/3802053
What this paper does with SQLancer
EPSC reuses SQLancer's statement generators to produce the statements it then rewrites into prepared form, and takes four oracles as baselines, two of which -- NoREC and TLP -- are SQLancer's, alongside CODDTest, which also came out of the project.
EPSC tests DBMSs by exploiting the fact that a statement can be written both as an ordinary SQL statement and as a prepared statement with literals bound as parameters. The two forms should behave identically, so any difference between them indicates a bug. The authors note that prepared statements, though widely used in production for performance and against SQL injection, have received far less testing attention. Applied to seven mature DBMSs, EPSC found 49 unique bugs, 31 confirmed and 10 fixed.
How it was classified
uses infrastructure — yes (generator)
M6 states the statement generators were reused from SQLancer for statement generation; the oracle itself is the paper's own.
We reused the statement generators from SQLancer [ 27] for statement generation, which are manually written and rule-based.
extends technique — no
Equivalent prepared statement construction is a new metamorphic relation rather than a generalisation of NoREC or TLP, which the paper classes as clause-equivalence and set-relation approaches respectively.
compares with — yes
M11 names NoREC, TLP, DQE and CODDTest as the baselines, and M12 explains which class each represents.
Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)Constant-Optimization-Driven Testing (CODDTest)
For our evaluation, we chose NoREC [ 25], TLP [ 26], DQE [ 31], and CODDTest [ 35] as baseline approaches.
Specifically, NoREC and DQE represent the class of approaches that detect logic bugs by leveraging clause equivalence; TLP represents the set-relation–based oracle design.
describes as state of the art — no
The baselines are described by the class of equivalence they exploit rather than as the state of the art.
SQLancer publications it cites (6)
Bibliography entries that resolved to a SQLancer publication, or to a paper by one of the project's authors. A sentence citing one of these numbers is a reference to SQLancer even when it never writes the name.
| # | Entry | Matched as |
|---|---|---|
| 1 | Jinsheng Ba and Manuel Rigger. 2023. Testing Database Engines via Query Plan Guidance. InProceedings of the 45th International Conference on Software Engineering(Melbourne, Victoria, Australia)(ICSE ’23). IEEE Press, ... | sqlancer publication · QPG |
| 2 | Jinsheng Ba and Manuel Rigger. 2024. Keep It Simple: Testing Databases via Differential Query Plans. doi:10.1145/3654991 | sqlancer publication · DQP |
| 25 | Manuel Rigger and Zhendong Su. 2020. Detecting optimization bugs in database engines via non-optimizing reference engine construction. InProceedings of the 28th ACM Joint Meeting on European Software Engineering Confe... | sqlancer publication · NOREC |
| 26 | Manuel Rigger and Zhendong Su. 2020. Finding bugs in database systems via query partitioning.Proc. ACM Program. Lang.4, OOPSLA, Article 211 (Nov. 2020), 30 pages. doi:10.1145/3428279 | sqlancer publication · TLP |
| 27 | Manuel Rigger and Zhendong Su. 2020. Testing Database Engines via Pivoted Query Synthesis. In14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, 667–682. https://www. us... | sqlancer publication · PQS |
| 35 | Chi Zhang and Manuel Rigger. 2025. Constant Optimization Driven Database System Testing. 2025), 24 pages. doi:10.1145/3709674 Received October 2025; revised January 2026; accepted February 2026 4, No. 3 (SIGMOD), Arti... | sqlancer publication · CODDTEST |
Every place it refers to SQLancer (30)
30 sentences, each stored verbatim from the extracted text with where it was found and how. “Citation marker” means the sentence names no tool at all and was reached through a reference number that resolved to a SQLancer publication.
| Id | Sentence | Found by | Where |
|---|---|---|---|
| M1 | These bugs can lead to system crashes, produce unexpected errors, or more subtly, to logic bugs [ 25], which cause the DBMS to silently produce incorrect results, making them hard for developers and users to notice. |
citation marker |
1 Introduction page 2 |
| M2 | Existing approaches leverage a variety of equivalence relations in DBMSs as metamorphic relations to determine whether logic bugs are triggered, including, but not limited to, equivalence across different systems [ 29], clauses [ 25,31], expressions [ 15,26,35], and configurations [ 2,17]. |
citation marker |
1 Introduction page 2 |
| M3 | Due to the large number of abnormal test cases generated and the repeated triggering of certain common errors, existing testing methods, such as SQLancer, ignore these errors and treat them as normal behavior. |
name |
1 Introduction page 3 |
| M4 | com/sqlancer/sqlancer/blob/main/src/sqlancer/common/query/ExpectedErrors. |
name |
1 Introduction page 3 |
| M5 | Logic bugs [ 25] are among the most common types of bugs in DBMSs and cause the system to produce incorrect results silently for certain statements. |
citation marker |
2 Background page 4 |
| M6 | We reused the statement generators from SQLancer [ 27] for statement generation, which are manually written and rule-based. |
name |
4 Evaluation page 11 |
| M7 | Moreover, all these DBMSs have been tested by existing works on detecting logic bugs in DBMSs [ 2,25–27,31,35]. |
citation marker |
4.1 Effectiveness page 12 |
| M8 | This is a standard practice for evaluating the effectiveness of logic bug detection methods [25, 26, 35]. |
citation marker |
4.1 Effectiveness page 12 |
| M9 | EPSC: Testing Database Management Systems via Equivalent Prepared Statement Construction 176:17 of prepared INSERT statements, it is beyond the reach of NoREC [ 25] and TLP [ 26], which target SELECT queries, and also DQE [ 31], whose detection of INSERT -related logic bugs is limited to WHERE-clause conditions. |
technique |
4.2 Selected Bugs page 16 |
| M10 | In SQLancer, the expression generator for DuckDB does not strictly validate the return types of generated expressions. |
name |
4.2 Selected Bugs page 18 |
| M11 | For our evaluation, we chose NoREC [ 25], TLP [ 26], DQE [ 31], and CODDTest [ 35] as baseline approaches. |
technique |
4.3 Compared with Other Approaches page 18 |
| M12 | Specifically, NoREC and DQE represent the class of approaches that detect logic bugs by leveraging clause equivalence; TLP represents the set-relation–based oracle design. |
technique |
4.3 Compared with Other Approaches page 18 |
| M13 | CODDTest represents the class of approaches that construct oracles by performing expression-equivalence transformations; a similar work, EET [ 15], adopts the same principle but cannot be run continuously—it terminates immediately after detecting a bug—making it unsuitable for long-running experiments. |
technique |
4.3 Compared with Other Approaches page 18 |
| M14 | EPSC: Testing Database Management Systems via Equivalent Prepared Statement Construction 176:19 configurations or optimizer hints to alter query execution paths for bug detection, as exemplified by Mozi [ 17], DQP [ 2], and TQS [ 33]. |
technique |
4.3 Compared with Other Approaches page 18 |
| M15 | Finally, all five tools directly reuse SQLancer’s test-case generation code, ensuring that the comparison of bug-detection capabilities focuses solely on the effectiveness of their testing oracles, while eliminating inconsistencies arising from differences in test-case generation implementations. | name | 4.3 Compared with Other Approaches page 19 |
| M16 | Overall, although EPSC did not find the largest total number of unique bugs—its count is smaller than that of NoREC, TLP, and CODDTest, but higher than DQE—it ranks first in terms of the number of bugs that were exclusively detected by a single tool, tying with TLP and outperforming NoREC, CODDTest, and DQE. | technique | 4.3 Compared with Other Approaches page 19 |
| M17 | The results show that one of the six bugs can be detected by NoREC, TLP, and CODDTest, while the remaining five bugs cannot be detected by any of the baseline oracles. | technique | 4.3 Compared with Other Approaches page 19 |
| M18 | Effectiveness and efficiency of EPSC compared to state-of-the-art test oracles Test oracles # of unique bugs # of oracle-exclusive bugs Code coverage # of unique query plans NoREC 23 4 63. | technique | 4.3 Compared with Other Approaches page 19 |
| M19 | 36% 172,812 TLP 24 6 63. | technique | 4.3 Compared with Other Approaches page 19 |
| M20 | 07% 475 CODDTest 21 2 62. | technique | 4.3 Compared with Other Approaches page 19 |
| M21 | This is largely attributed to its support for subqueries—similar to CODDTest—which increases query complexity and, consequently, plan diversity compared with NoREC and TLP. | technique | 4.3 Compared with Other Approaches page 20 |
| M22 | This difference arises because we directly adopt SQLancer’s query generators, which are implemented separately for each DBMS and therefore produce SQL statements with different proportions of erroneous. | name | 4.4 Ablation Study page 21 |
| M23 | NoREC [ 25] leverages the equivalence between expressions in the SELECT and WHERE clauses, assuming that an expression should evaluate to the same result in both contexts. | technique | 6 Related Work page 22 |
| M24 | DQE [ 31] extends NoREC by asserting that the same expression should evaluate consistently in the WHERE clause of SELECT, UPDATE, and DELETE statements. | technique | 6 Related Work page 22 |
| M25 | TLP [ 26] is based on the fact that an expression can evaluate to TRUE ,FALSE, or NULL. | technique | 6 Related Work page 22 |
| M26 | TQS [ 33] and Differential Query Plans (DQP) [ 2] detect logic bugs in join optimization by providing hints or modifying DBMS configurations to induce different query plans during query execution. | technique | 6 Related Work page 22 |
| M27 | Both EET [ 15] and CODDTest [ 35] transform expressions to construct equivalent queries. | technique | 6 Related Work page 22 |
| M28 | EET generates more complex but equivalent expressions by introducing subexpressions that always evaluate to TRUE or FALSE, while CODDTest creates simpler expressions by applying constant folding and propagation to replace parts of the original expression with equivalent constants. | technique | 6 Related Work page 22 |
| M29 | Generation-based approaches produce syntactically and semantically valid test cases based on the grammar and features supported by the target DBMSs, with SQLSmith [ 28] and SQLancer [ 27] being representative examples. | name | 6 Related Work page 23 |
| M30 | Query Plan Guidance (QPG) [ 1] was proposed to mitigate redundancy in randomly generated test cases and improve resource efficiency. | technique | 6 Related Work page 23 |