July 6, 2026
Query planner or chaos planner?
Evaluation order and nontermination in query languages
When one tiny check can freeze a whole query, commenters are already redesigning the rules
TLDR: The article says a search system can return the same answer in different ways, but one order may finish while another can run forever. Commenters reacted with a mix of “I built hacks for this already” and “wow, this small design choice hides a much bigger problem.”
A seemingly nerdy research post about database-style searches turned into a classic comment-section split: is this a deep computer science headache, or just another reminder that letting a system "figure it out later" can come back to haunt you? The author’s big point is surprisingly relatable in plain English: if a program can choose different orders to do its checks, one order might finish fast while another can get stuck forever. Same question, wildly different outcome. That’s the kind of thing that makes programmers start side-eyeing the phrase “implementation detail.”
The strongest reaction came from people who’ve clearly been burned before. One commenter jumped in with a link to their own project, basically saying, “Yep, I ran into this too, so I made the order flexible and gave people escape hatches.” That has real “I didn’t wait for the theory, I shipped a workaround” energy. Another commenter delivered the cooler, more academic hot take: this is really about what happens when a supposedly tidy, finite-looking system secretly allows endless computation. Translation: the article may look niche, but the problem is sneakily huge.
There wasn’t full-blown flame war chaos, but there was that delicious low-simmer tension between two worldviews: the database crowd saying “the engine should optimize it” and the programming-language crowd saying “we need predictable behavior.” The accidental comedy is brutal too: one harmless-looking test can turn a simple search into an eternal hang, which is basically the software version of “just one quick question” ruining your whole afternoon.
Key Points
- •The article presents λFS as a system that models relations as finite-support functions and stores them as tables such as hash tables or balanced trees.
- •λFS generalizes from boolean relations to finite maps over any codomain with a default value, including aggregation outputs and tensor-like data.
- •The author identifies recursion as future work for λFS because recursion introduces nontermination.
- •The article argues that once nontermination or effects are possible, evaluation order becomes semantically important, not just an implementation detail.
- •Using a query with finite tables and a potentially nonterminating user-defined predicate, the article shows that different execution orders can determine whether a relational query terminates.