I have a column containing strings, and I want to find those strings that are a prefix to a given string:

E.g. If the given string is ‘Hello World’ then rows containing ‘Hell’, and ‘Hello’ should match.

A query like
SELECT * FROM table t WHERE t.str <= 'Hello World' ORDER BY t.str DESC UNTIL ('Hello World' NOT_STARTS_WITH t.str)
would archive that.

(whatever SQL-function corresponds to the NOT_STARTS_WITH predicate)

So in my case I want to physically iterate over the b-tree index, until some condition is no longer satisfied.

1. The semantics of a “result set” is basically thrown out the window. A query is supposed to ask for data as if it were a set immediately available at the time of the query. Otherwise, you’re just using *procedural code* (which UNTIL just seems like perverting query syntax for the sake of an implicit loop). In other words, what about the halting problem? If you forget a WHERE clause, the worst case is you retrieve too much data. If you don’t make UNTIL have a sane terminating condition, then you can create an infinite loop. Depending on the database engine, this can cause a death spiral of locks, memory leaks, etc. The *semantics* of a query IS NOT a loop, so continuing a loop UNTIL some condition is non-sensical. You ask for the data, and based on the predicates the data either gets returned or they don’t, as a single result.

2. The argument that subqueries are doing too much whereas “one query” of UNTIL is faster is a non-argument. There IS NO “one query” for UNTIL: it’s semantically a loop of multiple queries (like you’d do with a procedure anyway). At least subqueries can be optimized by the planner. How is the query planner supposed to plan for something when there may not even be a genuine terminating condition?

But maybe there are genuine reasons for this, maybe either I’m not understanding or the concept isn’t being explained clearly enough. But then again, maybe that’s a sign that it’s not a good idea (given the list of problems stated already)?