Guaranteeing Row Order from SQLite VALUES Clause: Risks and Solutions

---

Understanding the Behavior of Row Ordering in SQLite’s VALUES Clause

Issue Overview: Implicit Order Preservation in VALUES Clauses and Window Functions

The core issue revolves around whether the order of rows generated by the VALUES clause in SQLite is preserved when used in conjunction with window functions like ROW_NUMBER() OVER (). Specifically, the question is whether the order of entries in a VALUES list (e.g., VALUES (5), (6), (1)) is guaranteed to match the sequence generated by ROW_NUMBER() when no explicit ORDER BY clause is present.

Key Observations from the Discussion:

1. Current Behavior: In SQLite versions up to at least 3.35.5, the VALUES clause appears to preserve the input order when used with ROW_NUMBER() OVER (). For example:

   SELECT ROW_NUMBER() OVER () AS rn, * 
   FROM (VALUES (5), (7), (1));
   

   Returns:

   rn | column1
   ---|--------
   1  | 5
   2  | 7
   3  | 1
   

   This matches the order of the VALUES list.

2. Theoretical vs. Practical Guarantees: SQL standards treat tables as unordered sets of rows. SQLite’s documentation explicitly states that row order is undefined unless an ORDER BY clause is used. However, the current implementation of the VALUES clause (via coroutines in the bytecode generator) preserves the input order. This behavior is undocumented and subject to change.

3. Conflicting Perspectives:

   • Some argue that the VALUES clause should be treated as a set, where order is irrelevant unless explicitly enforced.
   • Others point out that the VALUES clause’s order is preserved in practice due to SQLite’s internal mechanics, but this is not a contractual guarantee.

4. Impact of Pragmas: The reverse_unordered_selects pragma, which reverses the order of SELECT results without an ORDER BY, does not affect the VALUES clause. This suggests that VALUES is treated differently from regular table scans in SQLite’s query planner.

---

Possible Causes of Order Preservation or Instability

1. SQLite’s Internal Implementation of the VALUES Clause

The VALUES clause is implemented as a coroutine in SQLite’s Virtual Database Engine (VDBE). Coroutines generate rows on-the-fly in the order they appear lexically in the SQL statement. This explains why the input order is preserved in practice. However, coroutine-based execution is an implementation detail, not a documented feature. Future versions of SQLite might optimize VALUES clauses differently (e.g., using temporary tables or indexes), which could disrupt the observed order.

Bytecode Example (SQLite 3.24.0):

addr opcode     p1  p2  p3  p4       p5 comment
---- ------------- ---- ---- ---- ------------- -- -------------
0   Init      0   1   0          00 NULL
1   InitCoroutine 1   9   2          00 NULL
2   Integer    1   2   0          00 NULL
3   Yield     1   0   0          00 NULL
...

The coroutine generates rows sequentially, matching the VALUES list order.

2. Absence of Explicit ORDER BY

SQLite’s query planner does not guarantee row order unless an ORDER BY clause is present. This applies to all data sources, including derived tables, subqueries, and VALUES clauses. The lack of ORDER BY leaves the ordering at the mercy of the execution plan, which can vary based on:

• Index usage
• Query optimizations
• SQLite version changes

3. Misuse of Window Functions

The ROW_NUMBER() OVER () window function assigns numbers based on the natural order of rows as processed by SQLite. Without an ORDER BY in the OVER clause, the numbering is non-deterministic. For example:

SELECT ROW_NUMBER() OVER (ORDER BY column1) AS rn, column1
FROM (VALUES (5), (7), (1));

This guarantees order because of the explicit ORDER BY in the window function.

4. Reverse_Unordered_Selects Pragma Limitations

The reverse_unordered_selects pragma reverses the order of SELECT results without ORDER BY to expose reliance on implicit ordering. However, it does not affect VALUES clauses, creating a false sense of security. For example:

PRAGMA reverse_unordered_selects = 1;
SELECT * FROM (VALUES (1), (2), (3)); -- Order remains 1, 2, 3
SELECT * FROM some_table; -- Order reversed if no index/ORDER BY

---

Troubleshooting Steps, Solutions & Fixes

1. Enforce Order with Explicit ORDER BY

Always use ORDER BY to guarantee row order, even when using VALUES.

Example:

SELECT x.val, x.txt 
FROM x 
JOIN (
  SELECT ROW_NUMBER() OVER () AS rn, column1 
  FROM (VALUES (5), (6), (1)) 
  ORDER BY rn -- Explicitly order by row number
) AS tab ON x.val = tab.column1 
ORDER BY tab.rn;

2. Use Common Table Expressions (CTEs) with Ordinality

Simulate PostgreSQL’s WITH ORDINALITY by adding an explicit ordering column in a CTE.

Example:

WITH ordered_values (ord, val) AS (
  SELECT ROW_NUMBER() OVER (ORDER BY 1) AS ord, column1
  FROM (VALUES (5), (6), (1))
)
SELECT x.val, x.txt
FROM x
JOIN ordered_values ov ON x.val = ov.val
ORDER BY ov.ord;

3. Embed Ordering in the VALUES Clause

Include an explicit ordering column in the VALUES list.

Example:

SELECT x.val, x.txt
FROM x
JOIN (
  SELECT column1, column2 AS ord
  FROM (VALUES (5, 1), (6, 2), (1, 3))
) AS tab ON x.val = tab.column1
ORDER BY tab.ord;

4. Avoid Reliance on ROW_NUMBER() OVER ()

Use static ordinals or application logic to enforce order instead of assuming ROW_NUMBER() reflects VALUES order.

Example (Static Ordinals):

SELECT x.val, x.txt
FROM x
JOIN (
  SELECT 1 AS ord, 5 AS val UNION ALL
  SELECT 2 AS ord, 6 AS val UNION ALL
  SELECT 3 AS ord, 1 AS val
) AS tab ON x.val = tab.val
ORDER BY tab.ord;

5. Test with reverse_unordered_selects

Enable reverse_unordered_selects to validate whether your query relies on implicit ordering.

Steps:

PRAGMA reverse_unordered_selects = 1;
-- Run your query. If results change order, add an explicit ORDER BY.

6. Future-Proofing with SQLite Version Checks

Monitor SQLite release notes for changes to VALUES clause handling. Use conditional logic in your application to handle ordering if necessary.

7. Advocate for WITH ORDINALITY Support

While SQLite does not currently support WITH ORDINALITY, you can request this feature via the SQLite Forum or GitHub. Until then, use the workarounds above.

---

By adhering to these practices, you eliminate reliance on undocumented behavior and ensure consistent results across SQLite versions. The key takeaway is that order in SQL is never guaranteed unless explicitly enforced.