Suppose the abstract SQL you're considering has support for infinite-precision "big" integers that can store any integer values, and that these support *
, +
, and =
in WHERE
clauses.
Fix the schema as $k$ such integer values columns called x_1
, ..., x_k
.
Query equivalence in this schema is undecidable by a reduction to the satisfiability of Diophantine equations (Hilbert's 10th problem):
A system of Diophantine equations can be described as a multivariate-polynomial with integer coefficients $p(x_1, \dots, x_n) = 0$. Determining whether or not there is any tuple $(x_1, \dots, x_n) \in \mathbb{Z}^n$ that satisfies the equation is known to be an undecidable problem.
This condition can be directly represented as the WHERE
clause in the SQL described above: WHERE p(x_1, ..., x_k) = 0
(expanded using *
and +
).
Determining whether or not SELECT * FROM t WHERE p(x_1, ..., x_k) = 0
is equivalent to SELECT * FROM t WHERE false
is determining whether or not p(x_1, ..., x_k)
has some assignment of integers $x_1, \dots, x_k$ such that $p(x_1, \dots, p_k) = 0$; thus if we were able to determing the equivalence of SQL queries, we would be able to determine the satisfiability of Diophantine equations.
Because the satisfiability of Diophantine equations is undecidable, so must this query equivalence problem.
The above doesn't rely on any particularly interesting features of SQL -- it certainly doesn't rely on any tricky "Turing complete" features of many SQL implementations -- it relies solely on the embedded ability to evaluate expressions involving integers. That means this is unfortunately rather unenlightening, but it also makes it hard to pare down SQL to something that won't immediately have undecidability creep in.
Like any theoretical result on decidability would, this does require arbitrary precision integers are supported. While I don't know of any popular SQL implementation that truly supports unbounded integers, PostreSQL for one documents arbitrary-precision integers that support at least 1000 digits of precision, which is likely "large enough" to say an abstract model of SQL supports unbounded integers.
It might be worth analyzing a SQL without any support for arithmetic operators like +
and *
, though I think it might be possible to emulate both +
and *
using SUM
and JOIN
s; even without SUM
I think it may be possible.