@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/07.5-window.sqllogic

@@ -0,0 +1,1941 @@
+-- Window Function Tests
+-- Tests for SQL window functions with OVER clauses
+
+-- Setup test data
+CREATE TABLE sales (
+    id INTEGER PRIMARY KEY,
+    product TEXT,
+    region TEXT,
+    amount NUMERIC
+);
+
+INSERT INTO sales VALUES
+    (1, 'Widget', 'North', 100.50),
+    (2, 'Gadget', 'North', 75.25),
+    (3, 'Widget', 'South', 120.75),
+    (4, 'Gadget', 'South', 90.00),
+    (5, 'Widget', 'North', 85.50),
+    (6, 'Gadget', 'West', 110.25);
+
+-- Basic ROW_NUMBER() without partitioning
+SELECT id, product, ROW_NUMBER() OVER (ORDER BY id) as rn
+FROM sales ORDER BY id;
+→ [{"id":1,"product":"Widget","rn":1},{"id":2,"product":"Gadget","rn":2},{"id":3,"product":"Widget","rn":3},{"id":4,"product":"Gadget","rn":4},{"id":5,"product":"Widget","rn":5},{"id":6,"product":"Gadget","rn":6}]
+
+-- ROW_NUMBER() with PARTITION BY
+SELECT product, region, amount, ROW_NUMBER() OVER (PARTITION BY product ORDER BY amount) as rn
+FROM sales ORDER BY product, amount;
+→ [{"product":"Gadget","region":"North","amount":75.25,"rn":1},{"product":"Gadget","region":"South","amount":90.00,"rn":2},{"product":"Gadget","region":"West","amount":110.25,"rn":3},{"product":"Widget","region":"North","amount":85.50,"rn":1},{"product":"Widget","region":"North","amount":100.50,"rn":2},{"product":"Widget","region":"South","amount":120.75,"rn":3}]
+
+-- Test RANK() function
+SELECT product, amount, RANK() OVER (PARTITION BY product ORDER BY amount) as rnk
+FROM sales ORDER BY product, amount;
+→ [{"product":"Gadget","amount":75.25,"rnk":1},{"product":"Gadget","amount":90.00,"rnk":2},{"product":"Gadget","amount":110.25,"rnk":3},{"product":"Widget","amount":85.50,"rnk":1},{"product":"Widget","amount":100.50,"rnk":2},{"product":"Widget","amount":120.75,"rnk":3}]
+
+-- Test DENSE_RANK() function
+SELECT product, amount, DENSE_RANK() OVER (PARTITION BY product ORDER BY amount) as dense_rnk
+FROM sales ORDER BY product, amount;
+→ [{"product":"Gadget","amount":75.25,"dense_rnk":1},{"product":"Gadget","amount":90.00,"dense_rnk":2},{"product":"Gadget","amount":110.25,"dense_rnk":3},{"product":"Widget","amount":85.50,"dense_rnk":1},{"product":"Widget","amount":100.50,"dense_rnk":2},{"product":"Widget","amount":120.75,"dense_rnk":3}]
+
+-- Test SUM() OVER for running totals
+SELECT product, amount, SUM(amount) OVER (PARTITION BY product ORDER BY id ROWS UNBOUNDED PRECEDING) as running_sum
+FROM sales ORDER BY product, id;
+→ [{"product":"Gadget","amount":75.25,"running_sum":75.25},{"product":"Gadget","amount":90.00,"running_sum":165.25},{"product":"Gadget","amount":110.25,"running_sum":275.50},{"product":"Widget","amount":100.50,"running_sum":100.50},{"product":"Widget","amount":120.75,"running_sum":221.25},{"product":"Widget","amount":85.50,"running_sum":306.75}]
+
+-- Test COUNT() OVER for row counting
+SELECT region, product, COUNT(*) OVER (PARTITION BY region ORDER BY id ROWS UNBOUNDED PRECEDING) as cumulative_count
+FROM sales ORDER BY region, id;
+→ [{"region":"North","product":"Widget","cumulative_count":1},{"region":"North","product":"Gadget","cumulative_count":2},{"region":"North","product":"Widget","cumulative_count":3},{"region":"South","product":"Widget","cumulative_count":1},{"region":"South","product":"Gadget","cumulative_count":2},{"region":"West","product":"Gadget","cumulative_count":1}]
+
+-- Test AVG() OVER for running averages
+SELECT product, amount, AVG(amount) OVER (PARTITION BY product ORDER BY id ROWS UNBOUNDED PRECEDING) as running_avg
+FROM sales ORDER BY product, id;
+→ [{"product":"Gadget","amount":75.25,"running_avg":75.25},{"product":"Gadget","amount":90.00,"running_avg":82.625},{"product":"Gadget","amount":110.25,"running_avg":91.83333333333333},{"product":"Widget","amount":100.50,"running_avg":100.50},{"product":"Widget","amount":120.75,"running_avg":110.625},{"product":"Widget","amount":85.50,"running_avg":102.25}]
+
+-- Test multiple window functions in same query
+SELECT
+    product,
+    region,
+    amount,
+    ROW_NUMBER() OVER (ORDER BY amount DESC) as overall_rank,
+    ROW_NUMBER() OVER (PARTITION BY product ORDER BY amount DESC) as product_rank,
+    SUM(amount) OVER (PARTITION BY product) as product_total
+FROM sales ORDER BY amount DESC;
+→ [{"product":"Widget","region":"South","amount":120.75,"overall_rank":1,"product_rank":1,"product_total":306.75},{"product":"Gadget","region":"West","amount":110.25,"overall_rank":2,"product_rank":1,"product_total":275.50},{"product":"Widget","region":"North","amount":100.50,"overall_rank":3,"product_rank":2,"product_total":306.75},{"product":"Gadget","region":"South","amount":90.00,"overall_rank":4,"product_rank":2,"product_total":275.50},{"product":"Widget","region":"North","amount":85.50,"overall_rank":5,"product_rank":3,"product_total":306.75},{"product":"Gadget","region":"North","amount":75.25,"overall_rank":6,"product_rank":3,"product_total":275.50}]
+
+-- Test window functions with different frame specifications
+SELECT id, amount, SUM(amount) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) as windowed_sum
+FROM sales ORDER BY id;
+→ [{"id":1,"amount":100.50,"windowed_sum":175.75},{"id":2,"amount":75.25,"windowed_sum":296.50},{"id":3,"amount":120.75,"windowed_sum":286.00},{"id":4,"amount":90.00,"windowed_sum":296.25},{"id":5,"amount":85.50,"windowed_sum":285.75},{"id":6,"amount":110.25,"windowed_sum":195.75}]
+
+-- Test window frames with non-1 literal offsets
+SELECT id, amount, SUM(amount) OVER (ORDER BY id ROWS BETWEEN 2 PRECEDING AND 1 FOLLOWING) as windowed_sum
+FROM sales ORDER BY id;
+→ [{"id":1,"amount":100.50,"windowed_sum":175.75},{"id":2,"amount":75.25,"windowed_sum":296.50},{"id":3,"amount":120.75,"windowed_sum":386.50},{"id":4,"amount":90.00,"windowed_sum":371.50},{"id":5,"amount":85.50,"windowed_sum":406.50},{"id":6,"amount":110.25,"windowed_sum":285.75}]
+
+-- Test multiple window functions with same OVER clause
+SELECT product, amount,
+       ROW_NUMBER() OVER (PARTITION BY product ORDER BY amount) as rn,
+       RANK() OVER (PARTITION BY product ORDER BY amount) as rnk,
+       COUNT(*) OVER (PARTITION BY product ORDER BY amount ROWS UNBOUNDED PRECEDING) as cnt
+FROM sales ORDER BY product, amount;
+→ [{"product":"Gadget","amount":75.25,"rn":1,"rnk":1,"cnt":1},{"product":"Gadget","amount":90.00,"rn":2,"rnk":2,"cnt":2},{"product":"Gadget","amount":110.25,"rn":3,"rnk":3,"cnt":3},{"product":"Widget","amount":85.50,"rn":1,"rnk":1,"cnt":1},{"product":"Widget","amount":100.50,"rn":2,"rnk":2,"cnt":2},{"product":"Widget","amount":120.75,"rn":3,"rnk":3,"cnt":3}]
+
+-- Edge case: Window function with NULL handling
+CREATE TABLE sales_with_nulls (
+    id INTEGER PRIMARY KEY,
+    product TEXT,
+    amount NUMERIC NULL
+);
+
+INSERT INTO sales_with_nulls VALUES
+    (1, 'Widget', 100.00),
+    (2, 'Widget', NULL),
+    (3, 'Gadget', 75.00),
+    (4, 'Widget', 120.00),
+    (5, 'Gadget', NULL);
+
+SELECT product, amount, ROW_NUMBER() OVER (PARTITION BY product ORDER BY amount NULLS LAST) as rn
+FROM sales_with_nulls ORDER BY product, COALESCE(amount, 999999);
+→ [{"product":"Gadget","amount":75.00,"rn":1},{"product":"Gadget","amount":null,"rn":2},{"product":"Widget","amount":100.00,"rn":1},{"product":"Widget","amount":120.00,"rn":2},{"product":"Widget","amount":null,"rn":3}]
+
+-- Test aggregate window functions with NULLs
+SELECT product, amount,
+       COUNT(*) OVER (PARTITION BY product) as total_rows,
+       COUNT(amount) OVER (PARTITION BY product) as non_null_amounts,
+       SUM(amount) OVER (PARTITION BY product) as total_amount
+FROM sales_with_nulls ORDER BY product, COALESCE(amount, 999999);
+→ [{"product":"Gadget","amount":75.00,"total_rows":2,"non_null_amounts":1,"total_amount":75.00},{"product":"Gadget","amount":null,"total_rows":2,"non_null_amounts":1,"total_amount":75.00},{"product":"Widget","amount":100.00,"total_rows":3,"non_null_amounts":2,"total_amount":220.00},{"product":"Widget","amount":120.00,"total_rows":3,"non_null_amounts":2,"total_amount":220.00},{"product":"Widget","amount":null,"total_rows":3,"non_null_amounts":2,"total_amount":220.00}]
+
+DROP TABLE sales;
+DROP TABLE sales_with_nulls;
+
+-- Window Function Frame Equivalence Tests
+CREATE TABLE frame_test (id INTEGER PRIMARY KEY, value INTEGER, grp INTEGER);
+INSERT INTO frame_test VALUES
+(1, 10, 1), (2, 20, 1), (3, 30, 1),
+(4, 15, 2), (5, 25, 2), (6, 35, 2);
+
+-- Test equivalent window frame specifications produce same results
+SELECT value, grp,
+       SUM(value) OVER (PARTITION BY grp ORDER BY value ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as running_sum
+FROM frame_test ORDER BY grp, value;
+→ [{"value":10,"grp":1,"running_sum":10},{"value":20,"grp":1,"running_sum":30},{"value":30,"grp":1,"running_sum":60},{"value":15,"grp":2,"running_sum":15},{"value":25,"grp":2,"running_sum":40},{"value":35,"grp":2,"running_sum":75}]
+
+SELECT value, grp,
+       SUM(value) OVER (PARTITION BY grp ORDER BY value ROWS UNBOUNDED PRECEDING) as running_sum
+FROM frame_test ORDER BY grp, value;
+→ [{"value":10,"grp":1,"running_sum":10},{"value":20,"grp":1,"running_sum":30},{"value":30,"grp":1,"running_sum":60},{"value":15,"grp":2,"running_sum":15},{"value":25,"grp":2,"running_sum":40},{"value":35,"grp":2,"running_sum":75}]
+
+-- Test different but equivalent frame specifications for COUNT
+SELECT value, grp,
+       COUNT(*) OVER (PARTITION BY grp ORDER BY value ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as running_count
+FROM frame_test ORDER BY grp, value;
+→ [{"value":10,"grp":1,"running_count":1},{"value":20,"grp":1,"running_count":2},{"value":30,"grp":1,"running_count":3},{"value":15,"grp":2,"running_count":1},{"value":25,"grp":2,"running_count":2},{"value":35,"grp":2,"running_count":3}]
+
+SELECT value, grp,
+       COUNT(*) OVER (PARTITION BY grp ORDER BY value ROWS UNBOUNDED PRECEDING) as running_count
+FROM frame_test ORDER BY grp, value;
+→ [{"value":10,"grp":1,"running_count":1},{"value":20,"grp":1,"running_count":2},{"value":30,"grp":1,"running_count":3},{"value":15,"grp":2,"running_count":1},{"value":25,"grp":2,"running_count":2},{"value":35,"grp":2,"running_count":3}]
+
+DROP TABLE frame_test;
+
+-- =============================================================================
+-- Window PARTITION BY with collation tests
+-- =============================================================================
+
+-- NOCASE collation: PARTITION BY should group case-insensitively
+CREATE TABLE win_nocase (
+    id INTEGER PRIMARY KEY,
+    category TEXT COLLATE NOCASE,
+    val INTEGER
+);
+
+INSERT INTO win_nocase VALUES
+    (1, 'Alpha', 10),
+    (2, 'ALPHA', 20),
+    (3, 'alpha', 30),
+    (4, 'Beta', 40),
+    (5, 'BETA', 50);
+
+-- All 'alpha' variants should be in the same partition (3 rows), 'beta' variants together (2 rows)
+SELECT id, category, val,
+       ROW_NUMBER() OVER (PARTITION BY category ORDER BY id) as rn,
+       COUNT(*) OVER (PARTITION BY category) as partition_size
+FROM win_nocase ORDER BY id;
+→ [{"id":1,"category":"Alpha","val":10,"rn":1,"partition_size":3},{"id":2,"category":"ALPHA","val":20,"rn":2,"partition_size":3},{"id":3,"category":"alpha","val":30,"rn":3,"partition_size":3},{"id":4,"category":"Beta","val":40,"rn":1,"partition_size":2},{"id":5,"category":"BETA","val":50,"rn":2,"partition_size":2}]
+
+-- SUM within NOCASE partition
+SELECT id, category, val,
+       SUM(val) OVER (PARTITION BY category) as partition_total
+FROM win_nocase ORDER BY id;
+→ [{"id":1,"category":"Alpha","val":10,"partition_total":60},{"id":2,"category":"ALPHA","val":20,"partition_total":60},{"id":3,"category":"alpha","val":30,"partition_total":60},{"id":4,"category":"Beta","val":40,"partition_total":90},{"id":5,"category":"BETA","val":50,"partition_total":90}]
+
+-- DENSE_RANK with NOCASE ORDER BY
+CREATE TABLE win_rank_nocase (
+    id INTEGER PRIMARY KEY,
+    name TEXT COLLATE NOCASE,
+    score INTEGER
+);
+
+INSERT INTO win_rank_nocase VALUES
+    (1, 'Alice', 100),
+    (2, 'ALICE', 100),
+    (3, 'Bob', 90),
+    (4, 'Charlie', 80);
+
+-- 'Alice' and 'ALICE' should be considered equal for ranking under NOCASE
+SELECT id, name, score,
+       DENSE_RANK() OVER (ORDER BY name) as drnk
+FROM win_rank_nocase ORDER BY id;
+→ [{"id":1,"name":"Alice","score":100,"drnk":1},{"id":2,"name":"ALICE","score":100,"drnk":1},{"id":3,"name":"Bob","score":90,"drnk":2},{"id":4,"name":"Charlie","score":80,"drnk":3}]
+
+-- RANK with NOCASE ORDER BY
+SELECT id, name, score,
+       RANK() OVER (ORDER BY name) as rnk
+FROM win_rank_nocase ORDER BY id;
+→ [{"id":1,"name":"Alice","score":100,"rnk":1},{"id":2,"name":"ALICE","score":100,"rnk":1},{"id":3,"name":"Bob","score":90,"rnk":3},{"id":4,"name":"Charlie","score":80,"rnk":4}]
+
+-- NULL in PARTITION BY: NULLs should group together
+CREATE TABLE win_null_part (
+    id INTEGER PRIMARY KEY,
+    grp TEXT NULL,
+    val INTEGER
+);
+
+INSERT INTO win_null_part VALUES
+    (1, NULL, 10),
+    (2, NULL, 20),
+    (3, 'A', 30),
+    (4, 'A', 40);
+
+SELECT id, grp, val,
+       COUNT(*) OVER (PARTITION BY grp) as partition_size,
+       SUM(val) OVER (PARTITION BY grp) as partition_total
+FROM win_null_part ORDER BY id;
+→ [{"id":1,"grp":null,"val":10,"partition_size":2,"partition_total":30},{"id":2,"grp":null,"val":20,"partition_size":2,"partition_total":30},{"id":3,"grp":"A","val":30,"partition_size":2,"partition_total":70},{"id":4,"grp":"A","val":40,"partition_size":2,"partition_total":70}]
+
+DROP TABLE win_nocase;
+DROP TABLE win_rank_nocase;
+DROP TABLE win_null_part;
+
+-- =============================================================================
+-- LAG / LEAD tests
+-- =============================================================================
+
+CREATE TABLE nav_test (id INTEGER PRIMARY KEY, val INTEGER, grp TEXT);
+INSERT INTO nav_test VALUES
+(1, 10, 'A'), (2, 20, 'A'), (3, 30, 'A'),
+(4, 100, 'B'), (5, 200, 'B');
+
+-- Basic LAG (default offset = 1)
+SELECT id, val, LAG(val) OVER (ORDER BY id) as prev_val
+FROM nav_test ORDER BY id;
+→ [{"id":1,"val":10,"prev_val":null},{"id":2,"val":20,"prev_val":10},{"id":3,"val":30,"prev_val":20},{"id":4,"val":100,"prev_val":30},{"id":5,"val":200,"prev_val":100}]
+
+-- Basic LEAD (default offset = 1)
+SELECT id, val, LEAD(val) OVER (ORDER BY id) as next_val
+FROM nav_test ORDER BY id;
+→ [{"id":1,"val":10,"next_val":20},{"id":2,"val":20,"next_val":30},{"id":3,"val":30,"next_val":100},{"id":4,"val":100,"next_val":200},{"id":5,"val":200,"next_val":null}]
+
+-- LAG with explicit offset
+SELECT id, val, LAG(val, 2) OVER (ORDER BY id) as prev2_val
+FROM nav_test ORDER BY id;
+→ [{"id":1,"val":10,"prev2_val":null},{"id":2,"val":20,"prev2_val":null},{"id":3,"val":30,"prev2_val":10},{"id":4,"val":100,"prev2_val":20},{"id":5,"val":200,"prev2_val":30}]
+
+-- LEAD with explicit offset and default
+SELECT id, val, LEAD(val, 1, -1) OVER (ORDER BY id) as next_val
+FROM nav_test ORDER BY id;
+→ [{"id":1,"val":10,"next_val":20},{"id":2,"val":20,"next_val":30},{"id":3,"val":30,"next_val":100},{"id":4,"val":100,"next_val":200},{"id":5,"val":200,"next_val":-1}]
+
+-- LAG with default value
+SELECT id, val, LAG(val, 1, 0) OVER (ORDER BY id) as prev_val
+FROM nav_test ORDER BY id;
+→ [{"id":1,"val":10,"prev_val":0},{"id":2,"val":20,"prev_val":10},{"id":3,"val":30,"prev_val":20},{"id":4,"val":100,"prev_val":30},{"id":5,"val":200,"prev_val":100}]
+
+-- LAG/LEAD with PARTITION BY (should not cross partition boundaries)
+SELECT id, val, grp,
+       LAG(val) OVER (PARTITION BY grp ORDER BY id) as prev_val,
+       LEAD(val) OVER (PARTITION BY grp ORDER BY id) as next_val
+FROM nav_test ORDER BY id;
+→ [{"id":1,"val":10,"grp":"A","prev_val":null,"next_val":20},{"id":2,"val":20,"grp":"A","prev_val":10,"next_val":30},{"id":3,"val":30,"grp":"A","prev_val":20,"next_val":null},{"id":4,"val":100,"grp":"B","prev_val":null,"next_val":200},{"id":5,"val":200,"grp":"B","prev_val":100,"next_val":null}]
+
+DROP TABLE nav_test;
+
+-- =============================================================================
+-- FIRST_VALUE / LAST_VALUE tests
+-- =============================================================================
+
+CREATE TABLE fv_test (id INTEGER PRIMARY KEY, val INTEGER, grp TEXT);
+INSERT INTO fv_test VALUES
+(1, 10, 'A'), (2, 20, 'A'), (3, 30, 'A'),
+(4, 100, 'B'), (5, 200, 'B');
+
+-- FIRST_VALUE over entire partition
+SELECT id, val, grp,
+       FIRST_VALUE(val) OVER (PARTITION BY grp ORDER BY id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as first_val
+FROM fv_test ORDER BY id;
+→ [{"id":1,"val":10,"grp":"A","first_val":10},{"id":2,"val":20,"grp":"A","first_val":10},{"id":3,"val":30,"grp":"A","first_val":10},{"id":4,"val":100,"grp":"B","first_val":100},{"id":5,"val":200,"grp":"B","first_val":100}]
+
+-- LAST_VALUE over entire partition (must use explicit frame)
+SELECT id, val, grp,
+       LAST_VALUE(val) OVER (PARTITION BY grp ORDER BY id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as last_val
+FROM fv_test ORDER BY id;
+→ [{"id":1,"val":10,"grp":"A","last_val":30},{"id":2,"val":20,"grp":"A","last_val":30},{"id":3,"val":30,"grp":"A","last_val":30},{"id":4,"val":100,"grp":"B","last_val":200},{"id":5,"val":200,"grp":"B","last_val":200}]
+
+-- LAST_VALUE with default frame (ORDER BY present, no explicit frame = up to current row)
+SELECT id, val,
+       LAST_VALUE(val) OVER (ORDER BY id) as last_val
+FROM fv_test ORDER BY id;
+→ [{"id":1,"val":10,"last_val":10},{"id":2,"val":20,"last_val":20},{"id":3,"val":30,"last_val":30},{"id":4,"val":100,"last_val":100},{"id":5,"val":200,"last_val":200}]
+
+-- FIRST_VALUE without ORDER BY (entire partition)
+SELECT id, val, grp,
+       FIRST_VALUE(val) OVER (PARTITION BY grp) as first_val
+FROM fv_test ORDER BY id;
+→ [{"id":1,"val":10,"grp":"A","first_val":10},{"id":2,"val":20,"grp":"A","first_val":10},{"id":3,"val":30,"grp":"A","first_val":10},{"id":4,"val":100,"grp":"B","first_val":100},{"id":5,"val":200,"grp":"B","first_val":100}]
+
+DROP TABLE fv_test;
+
+-- =============================================================================
+-- PERCENT_RANK / CUME_DIST tests
+-- =============================================================================
+
+CREATE TABLE stat_test (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO stat_test VALUES (1, 10), (2, 20), (3, 20), (4, 30), (5, 40);
+
+-- PERCENT_RANK: (rank - 1) / (rows - 1)
+SELECT id, val, PERCENT_RANK() OVER (ORDER BY val) as pct_rank
+FROM stat_test ORDER BY id;
+→ [{"id":1,"val":10,"pct_rank":0},{"id":2,"val":20,"pct_rank":0.25},{"id":3,"val":20,"pct_rank":0.25},{"id":4,"val":30,"pct_rank":0.75},{"id":5,"val":40,"pct_rank":1}]
+
+-- CUME_DIST: (count of rows <= current) / total
+SELECT id, val, CUME_DIST() OVER (ORDER BY val) as cume
+FROM stat_test ORDER BY id;
+→ [{"id":1,"val":10,"cume":0.2},{"id":2,"val":20,"cume":0.6},{"id":3,"val":20,"cume":0.6},{"id":4,"val":30,"cume":0.8},{"id":5,"val":40,"cume":1}]
+
+-- Single-row partition: PERCENT_RANK = 0, CUME_DIST = 1
+SELECT val, PERCENT_RANK() OVER (PARTITION BY val ORDER BY val) as pct_rank,
+       CUME_DIST() OVER (PARTITION BY val ORDER BY val) as cume
+FROM stat_test WHERE val = 10;
+→ [{"val":10,"pct_rank":0,"cume":1}]
+
+DROP TABLE stat_test;
+
+-- =============================================================================
+-- NTILE tests
+-- =============================================================================
+
+CREATE TABLE ntile_test (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO ntile_test VALUES (1, 10), (2, 20), (3, 30), (4, 40), (5, 50);
+
+-- NTILE(2): 3 rows in bucket 1, 2 rows in bucket 2
+SELECT id, val, NTILE(2) OVER (ORDER BY id) as bucket
+FROM ntile_test ORDER BY id;
+→ [{"id":1,"val":10,"bucket":1},{"id":2,"val":20,"bucket":1},{"id":3,"val":30,"bucket":1},{"id":4,"val":40,"bucket":2},{"id":5,"val":50,"bucket":2}]
+
+-- NTILE(3): 2 rows in bucket 1, 2 in bucket 2, 1 in bucket 3
+SELECT id, val, NTILE(3) OVER (ORDER BY id) as bucket
+FROM ntile_test ORDER BY id;
+→ [{"id":1,"val":10,"bucket":1},{"id":2,"val":20,"bucket":1},{"id":3,"val":30,"bucket":2},{"id":4,"val":40,"bucket":2},{"id":5,"val":50,"bucket":3}]
+
+-- NTILE(5): 1 row per bucket
+SELECT id, val, NTILE(5) OVER (ORDER BY id) as bucket
+FROM ntile_test ORDER BY id;
+→ [{"id":1,"val":10,"bucket":1},{"id":2,"val":20,"bucket":2},{"id":3,"val":30,"bucket":3},{"id":4,"val":40,"bucket":4},{"id":5,"val":50,"bucket":5}]
+
+DROP TABLE ntile_test;
+
+-- =============================================================================
+-- RANGE BETWEEN tests (value-based window frames)
+-- =============================================================================
+
+CREATE TABLE range_test (id INTEGER PRIMARY KEY, val INTEGER, grp TEXT);
+INSERT INTO range_test VALUES
+(1, 10, 'A'), (2, 20, 'A'), (3, 20, 'A'), (4, 30, 'A'), (5, 50, 'A');
+
+-- RANGE CURRENT ROW: includes all peer rows (same ORDER BY value)
+SELECT id, val,
+       COUNT(*) OVER (ORDER BY val RANGE CURRENT ROW) as peer_count
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"peer_count":1},{"id":2,"val":20,"peer_count":2},{"id":3,"val":20,"peer_count":2},{"id":4,"val":30,"peer_count":1},{"id":5,"val":50,"peer_count":1}]
+
+-- RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW (default frame with ORDER BY)
+-- Should include all peers at current value
+SELECT id, val,
+       SUM(val) OVER (ORDER BY val RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as running_sum
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"running_sum":10},{"id":2,"val":20,"running_sum":50},{"id":3,"val":20,"running_sum":50},{"id":4,"val":30,"running_sum":80},{"id":5,"val":50,"running_sum":130}]
+
+-- Default frame (ORDER BY present) should be RANGE UNBOUNDED PRECEDING AND CURRENT ROW
+-- including peers
+SELECT id, val,
+       SUM(val) OVER (ORDER BY val) as running_sum
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"running_sum":10},{"id":2,"val":20,"running_sum":50},{"id":3,"val":20,"running_sum":50},{"id":4,"val":30,"running_sum":80},{"id":5,"val":50,"running_sum":130}]
+
+-- RANGE N PRECEDING: value-based offset
+SELECT id, val,
+       SUM(val) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND CURRENT ROW) as range_sum
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"range_sum":10},{"id":2,"val":20,"range_sum":50},{"id":3,"val":20,"range_sum":50},{"id":4,"val":30,"range_sum":70},{"id":5,"val":50,"range_sum":50}]
+
+-- RANGE BETWEEN N PRECEDING AND N FOLLOWING
+-- val=10: [5,15] → 10; val=20: [15,25] → 20+20=40; val=30: [25,35] → 30; val=50: [45,55] → 50
+SELECT id, val,
+       SUM(val) OVER (ORDER BY val RANGE BETWEEN 5 PRECEDING AND 5 FOLLOWING) as range_sum
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"range_sum":10},{"id":2,"val":20,"range_sum":40},{"id":3,"val":20,"range_sum":40},{"id":4,"val":30,"range_sum":30},{"id":5,"val":50,"range_sum":50}]
+
+-- RANGE UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING (same as ROWS)
+SELECT id, val,
+       SUM(val) OVER (ORDER BY val RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) as total
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"total":130},{"id":2,"val":20,"total":130},{"id":3,"val":20,"total":130},{"id":4,"val":30,"total":130},{"id":5,"val":50,"total":130}]
+
+-- FIRST_VALUE/LAST_VALUE with RANGE CURRENT ROW
+SELECT id, val,
+       FIRST_VALUE(id) OVER (ORDER BY val RANGE CURRENT ROW) as first_peer_id,
+       LAST_VALUE(id) OVER (ORDER BY val RANGE CURRENT ROW) as last_peer_id
+FROM range_test ORDER BY id;
+→ [{"id":1,"val":10,"first_peer_id":1,"last_peer_id":1},{"id":2,"val":20,"first_peer_id":2,"last_peer_id":3},{"id":3,"val":20,"first_peer_id":2,"last_peer_id":3},{"id":4,"val":30,"first_peer_id":4,"last_peer_id":4},{"id":5,"val":50,"first_peer_id":5,"last_peer_id":5}]
+
+DROP TABLE range_test;
+
+-- =============================================================================
+-- Streaming fast-path tests (rule: monotonic-window).
+--
+-- These verify the streaming emitter produces identical output to the buffered
+-- emitter on a variety of monotonic-input cases. The leaf table's PK provides
+-- the monotonicOn(id) advertisement that the rule keys off; queries below
+-- exercise ranking, navigation, and running-aggregate functions over
+-- ORDER BY id.
+-- =============================================================================
+
+CREATE TABLE stream_t (id INTEGER PRIMARY KEY, val INTEGER, grp TEXT);
+INSERT INTO stream_t VALUES
+  (1, 10, 'A'), (2, 20, 'A'), (3, 30, 'A'),
+  (4, 40, 'B'), (5, 50, 'B'), (6, 60, 'B');
+
+-- ROW_NUMBER over monotonic PK: streaming.
+SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM stream_t ORDER BY id;
+→ [{"id":1,"rn":1},{"id":2,"rn":2},{"id":3,"rn":3},{"id":4,"rn":4},{"id":5,"rn":5},{"id":6,"rn":6}]
+
+-- RANK / DENSE_RANK with no peer ties (PK is unique).
+SELECT id, val, RANK() OVER (ORDER BY id) AS r, DENSE_RANK() OVER (ORDER BY id) AS dr
+FROM stream_t ORDER BY id;
+→ [{"id":1,"val":10,"r":1,"dr":1},{"id":2,"val":20,"r":2,"dr":2},{"id":3,"val":30,"r":3,"dr":3},{"id":4,"val":40,"r":4,"dr":4},{"id":5,"val":50,"r":5,"dr":5},{"id":6,"val":60,"r":6,"dr":6}]
+
+-- LAG with default offset = 1.
+SELECT id, LAG(val) OVER (ORDER BY id) AS prv FROM stream_t ORDER BY id;
+→ [{"id":1,"prv":null},{"id":2,"prv":10},{"id":3,"prv":20},{"id":4,"prv":30},{"id":5,"prv":40},{"id":6,"prv":50}]
+
+-- LAG with literal offset 2 and a non-NULL default.
+SELECT id, LAG(val, 2, -1) OVER (ORDER BY id) AS prv2 FROM stream_t ORDER BY id;
+→ [{"id":1,"prv2":-1},{"id":2,"prv2":-1},{"id":3,"prv2":10},{"id":4,"prv2":20},{"id":5,"prv2":30},{"id":6,"prv2":40}]
+
+-- LEAD with default offset and no default value (NULL at boundary).
+SELECT id, LEAD(val) OVER (ORDER BY id) AS nxt FROM stream_t ORDER BY id;
+→ [{"id":1,"nxt":20},{"id":2,"nxt":30},{"id":3,"nxt":40},{"id":4,"nxt":50},{"id":5,"nxt":60},{"id":6,"nxt":null}]
+
+-- LEAD with literal offset 1 and a non-NULL default at partition end.
+SELECT id, LEAD(val, 1, -99) OVER (ORDER BY id) AS nxt FROM stream_t ORDER BY id;
+→ [{"id":1,"nxt":20},{"id":2,"nxt":30},{"id":3,"nxt":40},{"id":4,"nxt":50},{"id":5,"nxt":60},{"id":6,"nxt":-99}]
+
+-- Running SUM over default RANGE frame (UNBOUNDED PRECEDING TO CURRENT ROW).
+SELECT id, val, SUM(val) OVER (ORDER BY id) AS rs FROM stream_t ORDER BY id;
+→ [{"id":1,"val":10,"rs":10},{"id":2,"val":20,"rs":30},{"id":3,"val":30,"rs":60},{"id":4,"val":40,"rs":100},{"id":5,"val":50,"rs":150},{"id":6,"val":60,"rs":210}]
+
+-- Running MIN over explicit ROWS UNBOUNDED PRECEDING.
+SELECT id, val, MIN(val) OVER (ORDER BY id ROWS UNBOUNDED PRECEDING) AS rm FROM stream_t ORDER BY id;
+→ [{"id":1,"val":10,"rm":10},{"id":2,"val":20,"rm":10},{"id":3,"val":30,"rm":10},{"id":4,"val":40,"rm":10},{"id":5,"val":50,"rm":10},{"id":6,"val":60,"rm":10}]
+
+-- FIRST_VALUE caches the first row's expr for the partition.
+SELECT id, FIRST_VALUE(val) OVER (ORDER BY id) AS fv FROM stream_t ORDER BY id;
+→ [{"id":1,"fv":10},{"id":2,"fv":10},{"id":3,"fv":10},{"id":4,"fv":10},{"id":5,"fv":10},{"id":6,"fv":10}]
+
+-- LAST_VALUE under default frame (== current row in RANGE mode for unique keys).
+SELECT id, LAST_VALUE(val) OVER (ORDER BY id) AS lv FROM stream_t ORDER BY id;
+→ [{"id":1,"lv":10},{"id":2,"lv":20},{"id":3,"lv":30},{"id":4,"lv":40},{"id":5,"lv":50},{"id":6,"lv":60}]
+
+-- All-NULL expr column for LAG: defaults bubble through unchanged.
+CREATE TABLE stream_n (id INTEGER PRIMARY KEY, x INTEGER NULL);
+INSERT INTO stream_n VALUES (1, NULL), (2, NULL), (3, NULL);
+SELECT id, LAG(x) OVER (ORDER BY id) AS prv FROM stream_n ORDER BY id;
+→ [{"id":1,"prv":null},{"id":2,"prv":null},{"id":3,"prv":null}]
+
+-- Single-row "partition" — running aggregate equals the value itself.
+CREATE TABLE stream_one (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO stream_one VALUES (1, 42);
+SELECT id, val, SUM(val) OVER (ORDER BY id) AS rs FROM stream_one ORDER BY id;
+→ [{"id":1,"val":42,"rs":42}]
+
+-- Empty result via WHERE 1=0: streaming yields zero rows, no errors.
+SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM stream_t WHERE 1=0;
+→ []
+
+DROP TABLE stream_t;
+DROP TABLE stream_n;
+DROP TABLE stream_one;
+
+-- =============================================================================
+-- Shared-subtree row-context regression tests.
+--
+-- Two scalar subqueries against the same CTE share a plan subtree. Without
+-- serialized callback evaluation (see ticket
+-- serialize-emit-callbacks-returning-window), parallel `Promise.all` over
+-- the partition / ORDER BY callbacks raced on the shared inner-scan RowSlot
+-- under real async I/O (LevelDB store), producing wrong/null partition keys.
+-- =============================================================================
+
+create table tr (id integer primary key, v integer);
+insert into tr values (1, 10), (2, 20), (3, 30);
+
+-- PARTITION BY with two scalar subqueries against the same CTE.
+-- Both keys are constants (same for every row), so all rows land in a single
+-- partition and rn must be 1,2,3.
+with high as (select * from tr where v >= 20)
+select
+  row_number() over (
+    partition by (select count(*) from high), (select sum(v) from high)
+    order by id
+  ) as rn
+from tr
+order by id;
+→ [{"rn":1},{"rn":2},{"rn":3}]
+
+-- ORDER BY with two scalar subqueries against the same CTE.
+-- Both keys are constants, so the entire result is one peer group; the outer
+-- ORDER BY v then yields rn=1,2,3 in v order.
+with high as (select * from tr where v >= 20)
+select
+  v,
+  row_number() over (
+    order by (select count(*) from high), (select sum(v) from high)
+  ) as rn
+from tr
+order by v;
+→ [{"v":10,"rn":1},{"v":20,"rn":2},{"v":30,"rn":3}]
+
+drop table tr;
+
+-- =============================================================================
+-- Streaming sliding-frame tests (rule: monotonic-window).
+--
+-- These verify the streaming sliding-frame path under
+-- `ROWS BETWEEN n PRECEDING AND m FOLLOWING` and
+-- `RANGE BETWEEN <num> PRECEDING AND <num> FOLLOWING`. The leaf table's PK
+-- provides the monotonicOn(id) advertisement that the rule keys off.
+-- =============================================================================
+
+CREATE TABLE stream_s (id INTEGER PRIMARY KEY, val INTEGER, grp TEXT);
+INSERT INTO stream_s VALUES
+  (1, 10, 'A'), (2, 20, 'A'), (3, 30, 'A'),
+  (4, 40, 'B'), (5, 50, 'B'), (6, 60, 'B');
+
+-- ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING — SUM
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":30},{"id":2,"s":60},{"id":3,"s":90},{"id":4,"s":120},{"id":5,"s":150},{"id":6,"s":110}]
+
+-- ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING — COUNT
+SELECT id, COUNT(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS c
+FROM stream_s ORDER BY id;
+→ [{"id":1,"c":2},{"id":2,"c":3},{"id":3,"c":3},{"id":4,"c":3},{"id":5,"c":3},{"id":6,"c":2}]
+
+-- ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING — AVG
+SELECT id, AVG(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS a
+FROM stream_s ORDER BY id;
+→ [{"id":1,"a":15},{"id":2,"a":20},{"id":3,"a":30},{"id":4,"a":40},{"id":5,"a":50},{"id":6,"a":55}]
+
+-- ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING — MIN / MAX
+SELECT id,
+       MIN(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS mn,
+       MAX(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS mx
+FROM stream_s ORDER BY id;
+→ [{"id":1,"mn":10,"mx":20},{"id":2,"mn":10,"mx":30},{"id":3,"mn":20,"mx":40},{"id":4,"mn":30,"mx":50},{"id":5,"mn":40,"mx":60},{"id":6,"mn":50,"mx":60}]
+
+-- Asymmetric: ROWS BETWEEN 2 PRECEDING AND 0 FOLLOWING — SUM
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN 2 PRECEDING AND 0 FOLLOWING) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":10},{"id":2,"s":30},{"id":3,"s":60},{"id":4,"s":90},{"id":5,"s":120},{"id":6,"s":150}]
+
+-- One-sided right: ROWS BETWEEN 0 PRECEDING AND 2 FOLLOWING — SUM
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN 0 PRECEDING AND 2 FOLLOWING) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":60},{"id":2,"s":90},{"id":3,"s":120},{"id":4,"s":150},{"id":5,"s":110},{"id":6,"s":60}]
+
+-- Edge clamping: window much larger than partition (5 PRECEDING AND 5 FOLLOWING).
+-- Every row sees the full partition sum (210).
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN 5 PRECEDING AND 5 FOLLOWING) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":210},{"id":2,"s":210},{"id":3,"s":210},{"id":4,"s":210},{"id":5,"s":210},{"id":6,"s":210}]
+
+-- FIRST_VALUE / LAST_VALUE under sliding ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING
+SELECT id,
+       FIRST_VALUE(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS fv,
+       LAST_VALUE(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS lv
+FROM stream_s ORDER BY id;
+→ [{"id":1,"fv":10,"lv":20},{"id":2,"fv":10,"lv":30},{"id":3,"fv":20,"lv":40},{"id":4,"fv":30,"lv":50},{"id":5,"fv":40,"lv":60},{"id":6,"fv":50,"lv":60}]
+
+-- Single-row partition with a sliding frame (clamps to the lone row).
+CREATE TABLE stream_s_one (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO stream_s_one VALUES (1, 42);
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS s,
+       MIN(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS mn
+FROM stream_s_one ORDER BY id;
+→ [{"id":1,"s":42,"mn":42}]
+
+-- Sliding SUM with NULL argVals: nulls don't contribute to SUM/COUNT.
+CREATE TABLE stream_s_null (id INTEGER PRIMARY KEY, val INTEGER NULL);
+INSERT INTO stream_s_null VALUES (1, 10), (2, NULL), (3, 30), (4, NULL);
+SELECT id,
+       SUM(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS s,
+       COUNT(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) AS c
+FROM stream_s_null ORDER BY id;
+→ [{"id":1,"s":10,"c":1},{"id":2,"s":40,"c":2},{"id":3,"s":30,"c":1},{"id":4,"s":30,"c":1}]
+
+-- One-sided frames. `CURRENT ROW` is the offset-zero case of the bound it
+-- replaces, so these run the same streaming sliding-buffer state machine as
+-- the two-sided forms above.
+
+-- ROWS BETWEEN 2 PRECEDING AND CURRENT ROW — the trailing moving sum.
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":10},{"id":2,"s":30},{"id":3,"s":60},{"id":4,"s":90},{"id":5,"s":120},{"id":6,"s":150}]
+
+-- The start-only spelling `ROWS 2 PRECEDING` means the same frame.
+SELECT id, SUM(val) OVER (ORDER BY id ROWS 2 PRECEDING) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":10},{"id":2,"s":30},{"id":3,"s":60},{"id":4,"s":90},{"id":5,"s":120},{"id":6,"s":150}]
+
+-- ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING — the leading moving sum.
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":60},{"id":2,"s":90},{"id":3,"s":120},{"id":4,"s":150},{"id":5,"s":110},{"id":6,"s":60}]
+
+-- ROWS BETWEEN CURRENT ROW AND CURRENT ROW — the single current row.
+SELECT id, SUM(val) OVER (ORDER BY id ROWS BETWEEN CURRENT ROW AND CURRENT ROW) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":10},{"id":2,"s":20},{"id":3,"s":30},{"id":4,"s":40},{"id":5,"s":50},{"id":6,"s":60}]
+
+-- Trailing MIN / MAX (the running min-max shape over an ordered table).
+SELECT id,
+       MIN(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS mn,
+       MAX(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS mx
+FROM stream_s ORDER BY id;
+→ [{"id":1,"mn":10,"mx":10},{"id":2,"mn":10,"mx":20},{"id":3,"mn":20,"mx":30},{"id":4,"mn":30,"mx":40},{"id":5,"mn":40,"mx":50},{"id":6,"mn":50,"mx":60}]
+
+-- A one-sided frame and the default (running) frame in one query: distinct
+-- frames land in distinct window nodes and each keeps its own strategy.
+SELECT id,
+       SUM(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS trailing,
+       SUM(val) OVER (ORDER BY id) AS running
+FROM stream_s ORDER BY id;
+→ [{"id":1,"trailing":10,"running":10},{"id":2,"trailing":30,"running":30},{"id":3,"trailing":50,"running":60},{"id":4,"trailing":70,"running":100},{"id":5,"trailing":90,"running":150},{"id":6,"trailing":110,"running":210}]
+
+-- Trailing frame with PARTITION BY: the frame restarts at each partition.
+SELECT id, SUM(val) OVER (PARTITION BY grp ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS s
+FROM stream_s ORDER BY id;
+→ [{"id":1,"s":10},{"id":2,"s":30},{"id":3,"s":50},{"id":4,"s":40},{"id":5,"s":90},{"id":6,"s":110}]
+
+-- One-sided frame over NULL argument values: NULLs still don't contribute.
+SELECT id,
+       SUM(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS s,
+       COUNT(val) OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS c
+FROM stream_s_null ORDER BY id;
+→ [{"id":1,"s":10,"c":1},{"id":2,"s":10,"c":1},{"id":3,"s":30,"c":1},{"id":4,"s":30,"c":1}]
+
+DROP TABLE stream_s;
+DROP TABLE stream_s_one;
+DROP TABLE stream_s_null;
+
+-- RANGE BETWEEN with peer ties.
+-- Numeric ORDER BY column (val) with literal numeric offsets. The PK is id,
+-- so the rule may or may not fire here (depends on whether monotonicOn covers
+-- val); the test confirms correctness on whichever path runs.
+CREATE TABLE range_slide (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO range_slide VALUES
+  (1, 10), (2, 15), (3, 15), (4, 20), (5, 25), (6, 40);
+
+-- val=10: window=[0,20] → 10,15,15,20 = 60
+-- val=15 (twice): window=[5,25] → 10,15,15,20,25 = 85
+-- val=20: window=[10,30] → 10,15,15,20,25 = 85
+-- val=25: window=[15,35] → 15,15,20,25 = 75
+-- val=40: window=[30,50] → 40
+SELECT val, SUM(val) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND 10 FOLLOWING) AS s
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"s":60},{"val":15,"s":85},{"val":15,"s":85},{"val":20,"s":85},{"val":25,"s":75},{"val":40,"s":40}]
+
+-- COUNT under same RANGE frame.
+SELECT val, COUNT(*) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND 10 FOLLOWING) AS c
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"c":4},{"val":15,"c":5},{"val":15,"c":5},{"val":20,"c":5},{"val":25,"c":4},{"val":40,"c":1}]
+
+-- MIN / MAX under same RANGE frame.
+SELECT val,
+       MIN(val) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND 10 FOLLOWING) AS mn,
+       MAX(val) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND 10 FOLLOWING) AS mx
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"mn":10,"mx":20},{"val":15,"mn":10,"mx":25},{"val":15,"mn":10,"mx":25},{"val":20,"mn":10,"mx":25},{"val":25,"mn":15,"mx":25},{"val":40,"mn":40,"mx":40}]
+
+-- One-sided RANGE frames. In RANGE mode `CURRENT ROW` means the whole peer
+-- group, which is exactly the offset-zero interval [v, v] — so the two 15s
+-- must be treated identically at either edge of the frame.
+
+-- val=10: [0,10] → 10
+-- val=15 (twice): [5,15] → 10,15,15 = 40
+-- val=20: [10,20] → 10,15,15,20 = 60
+-- val=25: [15,25] → 15,15,20,25 = 75
+-- val=40: [30,40] → 40
+SELECT val, SUM(val) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND CURRENT ROW) AS s
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"s":10},{"val":15,"s":40},{"val":15,"s":40},{"val":20,"s":60},{"val":25,"s":75},{"val":40,"s":40}]
+
+-- The start-only spelling `RANGE 10 PRECEDING` means the same frame.
+SELECT val, SUM(val) OVER (ORDER BY val RANGE 10 PRECEDING) AS s
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"s":10},{"val":15,"s":40},{"val":15,"s":40},{"val":20,"s":60},{"val":25,"s":75},{"val":40,"s":40}]
+
+-- val=10: [10,20] → 10,15,15,20 = 60
+-- val=15 (twice): [15,25] → 15,15,20,25 = 75
+-- val=20: [20,30] → 20,25 = 45
+-- val=25: [25,35] → 25
+-- val=40: [40,50] → 40
+SELECT val, SUM(val) OVER (ORDER BY val RANGE BETWEEN CURRENT ROW AND 10 FOLLOWING) AS s
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"s":60},{"val":15,"s":75},{"val":15,"s":75},{"val":20,"s":45},{"val":25,"s":25},{"val":40,"s":40}]
+
+-- RANGE BETWEEN CURRENT ROW AND CURRENT ROW is exactly the peer group, so the
+-- two val=15 rows each see a frame of 2 rows and everything else sees 1.
+SELECT val,
+       COUNT(*) OVER (ORDER BY val RANGE BETWEEN CURRENT ROW AND CURRENT ROW) AS c,
+       SUM(val) OVER (ORDER BY val RANGE BETWEEN CURRENT ROW AND CURRENT ROW) AS s
+FROM range_slide ORDER BY val, id;
+→ [{"val":10,"c":1,"s":10},{"val":15,"c":2,"s":30},{"val":15,"c":2,"s":30},{"val":20,"c":1,"s":20},{"val":25,"c":1,"s":25},{"val":40,"c":1,"s":40}]
+
+-- NULL ordering values: a NULL-val row's RANGE window is the contiguous NULL
+-- peer span. Finite-val rows' RANGE windows exclude NULL rows entirely.
+CREATE TABLE range_null (id INTEGER PRIMARY KEY, val INTEGER NULL);
+INSERT INTO range_null VALUES (1, NULL), (2, NULL), (3, 10), (4, 20), (5, 30);
+-- ASC NULLS FIRST default (NULLs at the front of the sort order).
+-- val=NULL (id=1,2): window = both NULL rows. SUM(val)=NULL (no non-null vals).
+-- val=10: window=[5,15] over finite vals → just 10. SUM=10.
+-- val=20: window=[15,25] → 20. SUM=20.
+-- val=30: window=[25,35] → 30. SUM=30.
+SELECT id, val, SUM(val) OVER (ORDER BY val RANGE BETWEEN 5 PRECEDING AND 5 FOLLOWING) AS s
+FROM range_null ORDER BY id;
+→ [{"id":1,"val":null,"s":null},{"id":2,"val":null,"s":null},{"id":3,"val":10,"s":10},{"id":4,"val":20,"s":20},{"id":5,"val":30,"s":30}]
+
+-- Same, with an interval that reaches down to zero. NULL is not zero: the two
+-- NULL rows must still stay out of val=10's frame. (Regression — the buffered
+-- frame walk read the ORDER BY value with a bare `Number(...)`, which turns
+-- NULL into 0 and pulled both NULL rows in.)
+-- val=NULL (id=1,2): the NULL peer group → no non-null vals → SUM=NULL.
+-- val=10: [0,10] → 10.  val=20: [10,20] → 30.  val=30: [20,30] → 50.
+SELECT id, val, SUM(val) OVER (ORDER BY val RANGE BETWEEN 10 PRECEDING AND CURRENT ROW) AS s
+FROM range_null ORDER BY id;
+→ [{"id":1,"val":null,"s":null},{"id":2,"val":null,"s":null},{"id":3,"val":10,"s":10},{"id":4,"val":20,"s":30},{"id":5,"val":30,"s":50}]
+
+-- A fractional RANGE offset is not a supported frame offset on either physical
+-- path — it must raise, not quietly depend on which plan the optimizer picks.
+SELECT val, SUM(val) OVER (ORDER BY val RANGE BETWEEN 1.5 PRECEDING AND CURRENT ROW) AS s
+FROM range_null ORDER BY val, id;
+-- error: Invalid window frame offset
+
+DROP TABLE range_slide;
+DROP TABLE range_null;
+
+-- =============================================================================
+-- Window function nested inside an arithmetic / scalar projection expression.
+--
+-- Regression: a window function wrapped in a binary/scalar expression
+-- (e.g. `1000 - row_number() over (...)`) must keep the surrounding expression
+-- and substitute the window result back in — not collapse to the bare window
+-- column nor drop the projection entirely.
+-- =============================================================================
+
+CREATE TABLE nested_w (id INTEGER PRIMARY KEY, val INTEGER);
+INSERT INTO nested_w VALUES (1, 10), (2, 20), (3, 30);
+
+-- Literal minus window fn: arithmetic must actually apply (999, 998, 997).
+SELECT id, 1000 - ROW_NUMBER() OVER (ORDER BY id) AS v FROM nested_w ORDER BY id;
+→ [{"id":1,"v":999},{"id":2,"v":998},{"id":3,"v":997}]
+
+-- Window fn on the left of the operator.
+SELECT id, ROW_NUMBER() OVER (ORDER BY id) + 5 AS v FROM nested_w ORDER BY id;
+→ [{"id":1,"v":6},{"id":2,"v":7},{"id":3,"v":8}]
+
+-- Window fn nested inside a scalar function call.
+SELECT id, ABS(1 - ROW_NUMBER() OVER (ORDER BY id)) AS v FROM nested_w ORDER BY id;
+→ [{"id":1,"v":0},{"id":2,"v":1},{"id":3,"v":2}]
+
+-- Two different window functions in one arithmetic expression.
+-- rn (order by id) = 1,2,3 ; rank (order by val desc) = 3,2,1 ; rn-rank = -2,0,2.
+SELECT id, ROW_NUMBER() OVER (ORDER BY id) - RANK() OVER (ORDER BY val DESC) AS v
+FROM nested_w ORDER BY id;
+→ [{"id":1,"v":-2},{"id":2,"v":0},{"id":3,"v":2}]
+
+-- Mixed: plain columns + a window-wrapped column + a top-level window column.
+SELECT id, val,
+       1000 - ROW_NUMBER() OVER (ORDER BY id) AS adj,
+       ROW_NUMBER() OVER (ORDER BY id) AS rn
+FROM nested_w ORDER BY id;
+→ [{"id":1,"val":10,"adj":999,"rn":1},{"id":2,"val":20,"adj":998,"rn":2},{"id":3,"val":30,"adj":997,"rn":3}]
+
+DROP TABLE nested_w;
+
+-- =============================================================================
+-- Window functions in a GROUPED query.
+--
+-- The window runs over the GROUPED rows — one row per group — so
+-- `row_number() over (order by a) ... group by a` numbers the groups, not the
+-- underlying rows. Regression for
+-- bug-window-function-over-grouped-query-crashes: the grouped select list and
+-- the window select list used to be built by two separate walks, leaving a raw
+-- window-function expression in a projection *below* the node that computes
+-- window values ("No emitter registered for WindowFunctionCall").
+--
+-- No primary key on `wg`, so the functional-dependency GROUP BY reduction cannot
+-- rewrite the grouping keys out from under these.
+-- =============================================================================
+
+create table wg (a text, b text);
+insert into wg values ('x','1'),('y','2'),('x','3');
+
+-- Bare window function over the groups: two groups, so 1 and 2 (not 1..3).
+select a, row_number() over (order by a) as rn from wg group by a order by a;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- Alongside a real aggregate.
+select a, count(*) as c, row_number() over (order by a) as rn from wg group by a order by a;
+→ [{"a":"x","c":2,"rn":1},{"a":"y","c":1,"rn":2}]
+
+-- Window function wrapped in arithmetic keeps the surrounding expression.
+select a, 1000 - row_number() over (order by a) as adj from wg group by a order by a;
+→ [{"a":"x","adj":999},{"a":"y","adj":998}]
+
+-- HAVING filters groups before the window sees them, so rn restarts at 1.
+select a, row_number() over (order by a) as rn from wg group by a having count(*) > 1;
+→ [{"a":"x","rn":1}]
+
+-- ORDER BY a window alias.
+select a, row_number() over (order by a) as rn from wg group by a order by rn desc;
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+-- COUNT(*) OVER () counts GROUPS (2), not source rows (3).
+select a, count(*) over () as g from wg group by a order by a;
+→ [{"a":"x","g":2},{"a":"y","g":2}]
+
+-- LIMIT over the lot.
+select a, row_number() over (order by a) as rn from wg group by a order by rn limit 1;
+→ [{"a":"x","rn":1}]
+
+-- Grouped `select *` plus a window column. `group by a, b` collapses no rows
+-- here, so all three groups survive and the window numbers all three.
+select *, row_number() over (order by a, b) as rn from wg group by a, b order by a, b;
+→ [{"a":"x","b":"1","rn":1},{"a":"x","b":"3","rn":2},{"a":"y","b":"2","rn":3}]
+
+-- An aggregate already in the SELECT list may be spelled out again in the window
+-- specification — it reads the computed aggregate column.
+select a, count(*) as c, row_number() over (order by count(*) desc) as rn
+from wg group by a order by rn;
+→ [{"a":"x","c":2,"rn":1},{"a":"y","c":1,"rn":2}]
+
+-- A window specification is subject to the same GROUP BY restriction as the rest
+-- of the select list: the grouped rows carry only grouping keys and aggregate
+-- results, so an ungrouped column must fail at plan time (it used to reach the
+-- runtime as a base-table reference and die with an internal row-context error).
+select a, row_number() over (order by b) as rn from wg group by a;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a, count(*) over (partition by b) as c from wg group by a;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Same rule for a window function's arguments.
+select a, sum(b) over () as s from wg group by a;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A window function above an UNGROUPED aggregate: the aggregation yields exactly
+-- one implicit-group row, and the window runs over that single row, so
+-- `row_number()` is 1. There is no grouping-key redirect for this shape -- an
+-- ungrouped query has no grouping keys to rewrite onto -- and it needs none.
+-- (Matches PostgreSQL. Previously unreachable: the select list was rejected by
+-- the old ungrouped aggregate/non-aggregate mixing rule before the window phase
+-- ever ran.)
+select count(*) as c, row_number() over (order by count(*)) as rn from wg;
+→ [{"c":3,"rn":1}]
+
+-- The coverage rule still applies to that shape, and is what keeps it honest: the
+-- single implicit-group row carries only aggregate results, so a window
+-- specification or argument naming a base-table column is rejected with the same
+-- message a grouped query gets.
+select count(*) as c, row_number() over (order by a) as rn from wg;
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+select count(*) as c, sum(b) over () as s from wg;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A window function whose ARGUMENTS are column-free runs over that same single
+-- implicit-group row, so it sees exactly one row regardless of how many rows the
+-- aggregate consumed.
+select count(*) as c, sum(1) over (order by count(*)) as s from wg;
+→ [{"c":3,"s":1}]
+
+-- And the aggregate-inside-a-window-argument limitation is unchanged for the
+-- ungrouped shape (an aggregate over the aggregated row, not over the input).
+select count(*) as c, sum(count(*)) over () as s from wg;
+-- error: Aggregate function count not allowed in this context
+
+-- An aggregate that appears ONLY in the window specification is a named
+-- limitation, not an internal error: it would have to be collected into the
+-- aggregate node before the window phase runs.
+select a, row_number() over (order by count(*)) as rn from wg group by a;
+-- error: Aggregate function count in a window function's ORDER BY is only supported when the same aggregate also appears in the SELECT list
+
+-- Same limitation when the window spec's aggregate differs from the SELECT
+-- list's only in its argument (bug-aggregate-reuse-matching-ignores-arguments):
+-- `sum(a+0)` here is not `sum(b+0)`, so it is not the aggregate already
+-- collected for the SELECT list and must be rejected the same way.
+select a, sum(b+0) as s, row_number() over (order by sum(a+0)) as rn from wg group by a;
+-- error: Aggregate function sum in a window function's ORDER BY is only supported when the same aggregate also appears in the SELECT list
+
+-- The match is textual, so a *qualifier* divergence lands in that same
+-- limitation even though both spellings name the same column: `sum(w.b)` in the
+-- select list is not the fingerprint `sum(b)` the window spec asks for. Writing
+-- both the same way, or referencing the select-list alias, both work.
+select a, sum(w.b) as s, row_number() over (order by sum(b)) as rn from wg w group by a;
+-- error: Aggregate function sum in a window function's ORDER BY is only supported when the same aggregate also appears in the SELECT list
+
+-- Same limitation for a literal-case divergence
+-- (bug-aggregate-match-ignores-string-literal-case): a quoted string literal's
+-- case is part of an aggregate's identity, so `count(nullif(b,'a'))` here is not
+-- `count(nullif(b,'A'))` and must be rejected the same way — reading the wrong
+-- aggregate silently would be worse than this loud error.
+create table wgc (id integer primary key, g integer, b text);
+insert into wgc values (1, 1, 'A'), (2, 1, 'A'), (3, 1, 'a');
+
+select g, count(nullif(b,'A')) as c, row_number() over (order by count(nullif(b,'a'))) as w
+from wgc group by g;
+-- error: Aggregate function count in a window function's ORDER BY is only supported when the same aggregate also appears in the SELECT list
+
+drop table wgc;
+
+-- Two window functions with different specifications each get their own window
+-- output column; neither collapses onto the other's.
+select a, row_number() over (order by a) as p, count(*) over (partition by a) as q
+from wg group by a order by a;
+→ [{"a":"x","p":1,"q":1},{"a":"y","p":2,"q":1}]
+
+-- Two textually identical window functions resolve to their own columns too.
+select a, row_number() over (order by a) as p, row_number() over (order by a) as q
+from wg group by a order by a;
+→ [{"a":"x","p":1,"q":1},{"a":"y","p":2,"q":2}]
+
+-- A window specification may name an aggregate by its SELECT-list alias — that
+-- resolves through the aggregate output scope, like ORDER BY does.
+select a, count(*) as c, row_number() over (order by c) as rn from wg group by a order by rn;
+→ [{"a":"y","c":1,"rn":1},{"a":"x","c":2,"rn":2}]
+
+-- A grouping key may be named in a window specification by ANY spelling that
+-- denotes it, not only the one the GROUP BY used. The aggregate output scope
+-- registers a qualified name only when the GROUP BY key was itself written
+-- qualified, and registers a non-bare key only under a synthetic `group_N` name,
+-- so the other spellings bind to a base-table column the grouped row does not
+-- carry; the window phase redirects those subtrees onto the aggregate's own group
+-- output column (bug-window-spec-reads-base-table-column — they used to die with
+-- an internal "No row context found for column a" error).
+
+-- GROUP BY key written qualified, window spec qualified.
+select wg.a, row_number() over (order by wg.a) as rn from wg group by wg.a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- GROUP BY key written bare, window spec table-qualified.
+select a, row_number() over (order by wg.a) as rn from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- Same, alias-qualified through a FROM alias.
+select a, row_number() over (order by w.a) as rn from wg w group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- A non-bare grouping key spelled out again in the window specification.
+select a || '!' as k, row_number() over (order by a || '!') as rn from wg group by a || '!' order by rn;
+→ [{"k":"x!","rn":1},{"k":"y!","rn":2}]
+
+-- Same, in PARTITION BY: each group is its own partition, so every count is 1.
+select a || '!' as k, count(*) over (partition by a || '!') as c from wg group by a || '!' order by k;
+→ [{"k":"x!","c":1},{"k":"y!","c":1}]
+
+-- The grouping key nested inside a larger window-specification expression: the
+-- redirect recurses, so only the `a || '!'` subtree is rewritten.
+select a || '!' as k, row_number() over (order by upper(a || '!')) as rn from wg group by a || '!' order by rn;
+→ [{"k":"x!","rn":1},{"k":"y!","rn":2}]
+
+-- A window function ARGUMENT naming the grouping key another way works too.
+select a, max(wg.a) over () as m from wg group by a order by a;
+→ [{"a":"x","m":"y"},{"a":"y","m":"y"}]
+
+-- Identifier case is not part of a spelling: the fingerprint that matches a
+-- non-bare grouping key folds identifier case.
+select a || '!' as k, row_number() over (order by A || '!') as rn from wg group by a || '!' order by rn;
+→ [{"k":"x!","rn":1},{"k":"y!","rn":2}]
+
+-- A quoted literal's case IS part of it, so `a || 'x'` is not the grouping key
+-- `a || 'X'` and its bare `a` is an ungrouped reference.
+select a || 'X' as k, row_number() over (order by a || 'x') as rn from wg group by a || 'X';
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A qualified grouping key nested inside a larger window-specification expression.
+select a, row_number() over (order by upper(wg.a)) as rn from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- A wrapper around the grouping key survives the redirect.
+select a, row_number() over (order by a collate nocase) as rn from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- A *qualified* ungrouped column is not accidentally redirected onto a group key.
+select a, row_number() over (order by wg.b) as rn from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Neither is a same-shaped expression over the wrong column.
+select a || '!' as k, row_number() over (order by b || '!') as rn from wg group by a || '!';
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A grouping key may ALSO be named by the SELECT-list alias of the column that
+-- selects it, exactly as an *aggregate* alias can (see above). The alias is
+-- registered in the aggregate output scope beside the key's own name, so it
+-- resolves straight to the aggregate's group output column — the redirect above
+-- never has to see it.
+select a as k, row_number() over (order by k) as rn from wg group by a order by rn;
+→ [{"k":"x","rn":1},{"k":"y","rn":2}]
+
+-- In PARTITION BY as well. Each group is its own partition, so every count is 1.
+select a as k, count(*) over (partition by k) as c from wg group by a order by k;
+→ [{"k":"x","c":1},{"k":"y","c":1}]
+
+-- The alias may be defined AFTER the window function that names it: the scope is
+-- built from the whole select list before any window specification is.
+select count(*) over (partition by k) as w, a as k from wg group by a order by k;
+→ [{"w":1,"k":"x"},{"w":1,"k":"y"}]
+
+-- The GROUP BY key written qualified, the select-list column bare.
+select a as k, row_number() over (order by k) as rn from wg group by wg.a order by rn;
+→ [{"k":"x","rn":1},{"k":"y","rn":2}]
+
+-- A COMPUTED grouping key's alias resolves the same way — the select-list column is
+-- matched to its key by expression identity rather than by attribute.
+select upper(a) as k, row_number() over (order by k) as rn from wg group by upper(a) order by rn;
+→ [{"k":"X","rn":1},{"k":"Y","rn":2}]
+
+select a || '!' as k, row_number() over (order by k) as rn from wg group by a || '!' order by rn;
+→ [{"k":"x!","rn":1},{"k":"y!","rn":2}]
+
+-- Beside an aggregate alias, both resolving through the same scope.
+select a as k, count(*) as c, row_number() over (order by k) as rn from wg group by a order by rn;
+→ [{"k":"x","c":2,"rn":1},{"k":"y","c":1,"rn":2}]
+
+-- Identifier case is immaterial, in either direction.
+select a as k, row_number() over (order by K) as rn from wg group by a order by rn;
+→ [{"k":"x","rn":1},{"k":"y","rn":2}]
+
+-- The alias reaches inside a SUBQUERY in the specification, where it correlates back
+-- to the grouping key like any other spelling of it. `wg` has 2 rows with a='x' and 1
+-- with a='y', so y sorts first.
+select a as k, row_number() over (order by (select count(*) from wg t where t.a = k)) as rn
+from wg group by a order by rn;
+→ [{"k":"y","rn":1},{"k":"x","rn":2}]
+
+-- DELIBERATE: the alias SHADOWS a same-named base-table column. `b` is a real
+-- column of `wg`, but inside the specification the alias wins and `b` is the
+-- grouping key `a`. This is the rule an aggregate alias already had; it is not an
+-- accident of registration order.
+select a as b, row_number() over (order by b) as rn from wg group by a order by rn;
+→ [{"b":"x","rn":1},{"b":"y","rn":2}]
+
+-- DELIBERATE, the other way: an alias is the LOWEST-precedence name in that scope,
+-- so it does not outrank a GROUPING KEY of the same name. Here `b` is both the
+-- alias of the `a` key and a grouping key in its own right; `partition by b`
+-- partitions on the grouping key `b` (three distinct values → three partitions of
+-- one row), not on the alias (which would give two partitions of 2 and 1).
+select a as b, count(*) over (partition by b) as c from wg group by a, b order by b;
+→ [{"b":"x","c":1},{"b":"x","c":1},{"b":"y","c":1}]
+
+-- Two aliases naming DIFFERENT grouping keys collide, and nothing in the scope can
+-- arbitrate, so a bare reference to the shared name is ambiguous.
+select a as k, b as k, row_number() over (order by k) as rn from wg group by a, b;
+-- error: ambiguous column name: k
+
+-- The SELECT list itself is NOT widened: a select-list column still cannot name a
+-- sibling column's alias. The list is built against the pre-aggregate scope, before
+-- the aggregate output scope exists.
+select a as k, k as k2 from wg group by a;
+-- error: Column not found: k
+
+-- A quoted alias may contain a dot, which the scope's flat string key cannot tell
+-- apart from the qualified spelling of a grouping key (`wg.a`). The alias is skipped
+-- rather than registered, so this query keeps planning exactly as it did before
+-- aliases were registered at all — registering it raised the internal-sounding
+-- "Symbol 'wg.a' already exists in the same scope."
+select wg.a as "wg.a", row_number() over (order by a) as rn from wg group by wg.a order by rn;
+→ [{"wg.a":"x","rn":1},{"wg.a":"y","rn":2}]
+
+-- Same skip when the dotted alias names a DIFFERENT key than the qualified spelling
+-- it collides with: `"wg.b"` in the specification is the grouping key `b`, not the
+-- alias of `a`. Alias precedence is lowest, qualified names included.
+select wg.a as "wg.b", row_number() over (order by "wg.b") as rn from wg group by wg.a, wg.b order by rn;
+→ [{"wg.b":"x","rn":1},{"wg.b":"y","rn":2},{"wg.b":"x","rn":3}]
+
+-- An alias whose grouping key came from a GROUP BY ORDINAL resolves like any other:
+-- the ordinal is expanded to the select-list expression before the keys are indexed.
+select a as k, row_number() over (order by k) as rn from wg group by 1 order by rn;
+→ [{"k":"x","rn":1},{"k":"y","rn":2}]
+
+-- The alias survives composition: a grouped, windowed query whose specification names
+-- one is an ordinary subquery source, and a UNION arm of one.
+select * from (select a as k, count(*) over (partition by k) as c from wg group by a) z order by k;
+→ [{"k":"x","c":1},{"k":"y","c":1}]
+
+select a as k, count(*) over (partition by k) as c from wg group by a
+union all select a, 1 from wg order by k, c;
+→ [{"k":"x","c":1},{"k":"x","c":1},{"k":"x","c":1},{"k":"y","c":1},{"k":"y","c":1}]
+
+-- A grouped, windowed query composes as a subquery source: its window column is
+-- an ordinary output column to the enclosing query.
+with q as (select a, row_number() over (order by a) as rn from wg group by a)
+select * from q where rn > 1;
+→ [{"a":"y","rn":2}]
+
+-- A window specification may also contain a SUBQUERY that correlates back to the
+-- grouping key. The redirect and the coverage check both descend through the
+-- subquery to reach it, keying off the attribute ids the aggregate's INPUT
+-- produces so the subquery's own columns are left alone
+-- (bug-window-spec-subquery-reads-base-table-column — every shape below used to
+-- die with an internal "No row context found for column a" error).
+
+-- Scalar subquery in ORDER BY: `max(b)` per group is '3' for a='x' and '2' for
+-- a='y', so ascending puts y first.
+select a, row_number() over (order by (select max(t.b) from wg t where t.a = wg.a)) as rn
+from wg group by a order by rn;
+→ [{"a":"y","rn":1},{"a":"x","rn":2}]
+
+-- `exists (…)` correlated on the grouping key: true only for the group that has a
+-- row with b > '2' (a='x'), so y sorts first.
+select a, row_number() over (order by (case when exists (select 1 from wg t where t.a = wg.a and t.b > '2') then 1 else 0 end)) as rn
+from wg group by a order by rn;
+→ [{"a":"y","rn":1},{"a":"x","rn":2}]
+
+-- `x in (select …)`, correlated on both sides of the membership test.
+select a, row_number() over (order by (case when wg.a in (select t.a from wg t where t.a = wg.a and t.b > '2') then 1 else 0 end)) as rn
+from wg group by a order by rn;
+→ [{"a":"y","rn":1},{"a":"x","rn":2}]
+
+-- In a window function's ARGUMENT rather than its specification: the per-group
+-- values '3' and '2' summed over the whole (unpartitioned) window.
+select a, sum((select max(t.b) from wg t where t.a = wg.a)) over () as s
+from wg group by a order by a;
+→ [{"a":"x","s":5},{"a":"y","s":5}]
+
+-- In PARTITION BY: the correlated subquery yields a distinct value per group, so
+-- every partition holds exactly one grouped row.
+select a, count(*) over (partition by (select max(t.b) from wg t where t.a = wg.a)) as c
+from wg group by a order by a;
+→ [{"a":"x","c":1},{"a":"y","c":1}]
+
+-- The mirror image, and the reason the redirect cannot simply match by name: a
+-- BARE `a` written inside the subquery names the subquery's OWN `t.a`, not the
+-- grouping key, so the predicate is the tautology `t.a = t.a` and every group sees
+-- the same global `max(b)`. One partition of two grouped rows, not two of one.
+select a, count(*) over (partition by (select max(t.b) from wg t where t.a = a)) as c
+from wg group by a order by a;
+→ [{"a":"x","c":2},{"a":"y","c":2}]
+
+-- A correlated reference to a NON-grouped column is rejected at plan time, with the
+-- same message a bare ungrouped column in a window specification gets.
+select a, row_number() over (order by (select max(t.b) from wg t where t.b = wg.b)) as rn
+from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Same rejection when the ungrouped column is only on one side of the correlation.
+select a, row_number() over (order by (select count(*) from wg t where t.a = wg.b)) as rn
+from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- An UNCORRELATED subquery in a window specification reads nothing of this query's
+-- and is left entirely alone.
+select a, row_number() over (order by (select max(t.b) from wg t), a) as rn
+from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- A window specification inside a GROUPED SUBQUERY may correlate to the ENCLOSING
+-- query. `o.a` is not one of the inner query's pre-grouping columns, so the inner
+-- coverage check has no business rejecting it — it used to, because its only
+-- vocabulary was "is this an aggregate output column".
+select o.a,
+       (select count(*) from (select row_number() over (order by i.b, o.a) rn
+                              from wg i where i.a = o.a group by i.b) z) c
+from wg o group by o.a order by o.a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+-- A whole SUBQUERY can be the grouping key, and repeating it verbatim in the window
+-- specification must resolve to that key's output column. It is matched by identity
+-- fingerprint at the top level of the specification, where the expression is written
+-- in this query's own scope — the "does this subtree read only pre-grouping columns"
+-- test that guards the same rule INSIDE a subquery cannot be applied here, because a
+-- correlated grouping key legitimately reads the subquery's columns too. Two groups:
+-- max(b) is '3' for a='x' and '2' for a='y'.
+select count(*) as n, row_number() over (order by (select max(t.b) from wg t where t.a = wg.a)) as rn
+from wg group by (select max(t.b) from wg t where t.a = wg.a) order by rn;
+→ [{"n":1,"rn":1},{"n":2,"rn":2}]
+
+-- The mirror: an expression grouping key named from INSIDE a subquery in the
+-- specification. `wgk` has no column `a`, so the bare `a` resolves outward to this
+-- query's grouping key and IS redirected. Each group matches one `wgk` row, so both
+-- grouped rows land in the same partition.
+create table wgk (c text);
+insert into wgk values ('x!'), ('y!'), ('z!');
+
+select a || '!' as k, count(*) over (partition by (select count(*) from wgk t where t.c = a || '!')) as c
+from wg group by a || '!' order by k;
+→ [{"k":"x!","c":2},{"k":"y!","c":2}]
+
+drop table wgk;
+
+-- An aggregate inside a subquery in the window specification belongs to the
+-- SUBQUERY, so its arguments get no exemption from the coverage check: `wg.b` is a
+-- correlated reference to an ungrouped column of the grouped query and is rejected at
+-- plan time. (Only this query's OWN top-level aggregates read pre-grouping columns by
+-- definition — see the `count(*) over (order by count(*) desc)` cases above.)
+select a, row_number() over (order by (select max(wg.b) from wg t)) as rn
+from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a, row_number() over (order by (select count(wg.b) from wg t where t.a = wg.a)) as rn
+from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- The GROUPING key inside such an aggregate is legal, and is redirected onto the
+-- aggregate's output column: max('x'||b) is 'x3', max('y'||b) is 'y3'.
+select a, row_number() over (order by (select max(wg.a || t.b) from wg t)) as rn
+from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- A CTE is planned ONCE and shared by every reference to it, so when the grouped
+-- query and a subquery in its window specification both read the same CTE, the CTE
+-- body is reachable from both. Its own columns are not this query's pre-grouping
+-- columns and must not be treated as such — this rejected with "Column 'b' must
+-- appear in the GROUP BY clause", naming a column written only inside the CTE.
+with c as (select a, b from wg where b <> '')
+select a, row_number() over (order by (select count(*) from c z), a) as rn
+from c group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- Same shape, correlated: the redirect still reaches the grouping key through the
+-- shared CTE. `max(b)` is '3' for a='x' and '2' for a='y', so y sorts first.
+with c as (select a, b from wg where b <> '')
+select a, row_number() over (order by (select max(t.b) from c t where t.a = c.a)) as rn
+from c group by a order by rn;
+→ [{"a":"y","rn":1},{"a":"x","rn":2}]
+
+-- And an ungrouped correlated reference is still rejected when the CTE is shared.
+with c as (select a, b from wg where b <> '')
+select a, row_number() over (order by (select max(t.b) from c t where t.b = c.b)) as rn
+from c group by a;
+-- error: Column 'c.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A RECURSIVE CTE is shared the same way.
+with recursive r(n) as (select 1 union all select n + 1 from r where n < 3)
+select n, row_number() over (order by (select count(*) from r z), n) as rn
+from r group by n order by rn;
+→ [{"n":1,"rn":1},{"n":2,"rn":2},{"n":3,"rn":3}]
+
+-- =============================================================================
+-- The SELECT LIST of a grouped query names a grouping key.
+--
+-- Same claim as the window-specification cases above, one clause over: a
+-- select-list reference to a grouping key must resolve to the AggregateNode's own
+-- group output column, whatever spelling it used. The aggregate output scope only
+-- holds a grouping key under the names the query literally wrote, so a qualifier
+-- the GROUP BY did not use, a FROM-alias qualifier, or a key nested inside a
+-- bigger expression all fall through to a BASE-TABLE attribute the grouped row
+-- does not carry. `buildFinalAggregateProjections` runs the same grouping-key
+-- redirect the window phase does — both through `redirectPostAggregate`
+-- (bug-qualified-group-key-in-select-list-breaks-window-query).
+--
+-- Each windowed case below is paired with its NON-window twin. The twin answers
+-- correctly today only because `emit/aggregate.ts` publishes a representative
+-- source row of the group around each yield and the projection sits directly on
+-- that yield (docs/runtime.md § Corollary: a published source row reaches only the
+-- adjacent consumer) — the window function is simply the operator that buffers in
+-- between and exposes the mis-binding. Both spellings must bind the same way, so
+-- both are pinned.
+-- =============================================================================
+
+-- The reported shape: table-qualified select-list key, bare GROUP BY. The output
+-- column is named `a`, not `wg.a` — the alias comes from the written column name
+-- and the redirect must not change it.
+select wg.a, row_number() over (order by a) as rn from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select wg.a, count(*) as c from wg group by a order by a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+-- Qualified through a FROM ALIAS rather than the table name. Attribute ids are
+-- minted per relation instance, so `w.a` and `wg.a` and bare `a` all land on the
+-- same base attribute and the match is qualifier-independent.
+select w.a, row_number() over (order by a) as rn from wg w group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select w.a, count(*) as c from wg w group by a order by a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+-- With an explicit alias, which the redirect leaves alone.
+select wg.a as k, row_number() over (order by a) as rn from wg group by a order by rn;
+→ [{"k":"x","rn":1},{"k":"y","rn":2}]
+
+-- Alongside an aggregate, with the window ordered by that aggregate's alias.
+select wg.a, count(*) as c, row_number() over (order by c) as rn from wg group by a order by rn;
+→ [{"a":"y","c":1,"rn":1},{"a":"x","c":2,"rn":2}]
+
+-- Window specification qualified as well, so both redirects run on one query.
+select wg.a, row_number() over (order by wg.a) as rn from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+-- A qualified grouping key NESTED inside a larger select-list expression: the walk
+-- recurses, so only the `wg.a` reference is rewritten.
+select upper(wg.a) as k, row_number() over (order by a) as rn from wg group by a order by rn;
+→ [{"k":"X","rn":1},{"k":"Y","rn":2}]
+
+select upper(wg.a) as k from wg group by a order by k;
+→ [{"k":"X"},{"k":"Y"}]
+
+-- A COMPUTED grouping key nested inside a larger select-list expression. The
+-- whole-expression fingerprint fast path cannot see this one (`upper(a || '!')` is
+-- not the key `a || '!'`); the redirect matches the inner subtree instead.
+select upper(a || '!') as k, row_number() over (order by a || '!') as rn from wg group by a || '!' order by rn;
+→ [{"k":"X!","rn":1},{"k":"Y!","rn":2}]
+
+select upper(a || '!') as k from wg group by a || '!' order by k;
+→ [{"k":"X!"},{"k":"Y!"}]
+
+-- A qualified key inside an ordinary binary expression.
+select wg.a || '?' as k, row_number() over (order by a) as rn from wg group by a order by rn;
+→ [{"k":"x?","rn":1},{"k":"y?","rn":2}]
+
+select wg.a || '?' as k from wg group by a order by k;
+→ [{"k":"x?"},{"k":"y?"}]
+
+-- NON-WINDOW REGRESSIONS. These all worked before the select-list redirect existed
+-- and must return exactly the same rows with it in place.
+
+-- Bare key — already bound to the group column through the aggregate output scope.
+select a, count(*) as c from wg group by a order by a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+-- Whole-expression fingerprint fast path, which runs BEFORE the redirect and is
+-- left untouched by it.
+select a || '!' as k, count(*) as c from wg group by a || '!' order by k;
+→ [{"k":"x!","c":2},{"k":"y!","c":1}]
+
+-- The `SELECT *` arm emits group-column references of its own and is untouched.
+select * from wg group by a, b order by a, b;
+→ [{"a":"x","b":"1"},{"a":"x","b":"3"},{"a":"y","b":"2"}]
+
+select *, row_number() over (order by a, b) as rn from wg group by a, b order by rn;
+→ [{"a":"x","b":"1","rn":1},{"a":"x","b":"3","rn":2},{"a":"y","b":"2","rn":3}]
+
+-- A GROUP BY ORDINAL is expanded to the select-list expression before the keys are
+-- indexed, so the redirect sees an ordinary bare key.
+select a, count(*) as c from wg group by 1 order by a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+select a, count(*) as c, row_number() over (order by a) as rn from wg group by 1 order by rn;
+→ [{"a":"x","c":2,"rn":1},{"a":"y","c":1,"rn":2}]
+
+-- TWO projections onto the SAME grouping key. Both now carry the same input
+-- attribute id; the duplicate output name is disambiguated as `a:1`, exactly as a
+-- bare `select a, a` already was.
+select wg.a, a from wg group by a order by 1;
+→ [{"a":"x","a:1":"x"},{"a":"y","a:1":"y"}]
+
+select wg.a, a, row_number() over (order by a) as rn from wg group by a order by rn;
+→ [{"a":"x","a:1":"x","rn":1},{"a":"y","a:1":"y","rn":2}]
+
+-- HAVING resolves through its own hybrid scope; an aggregate reference resolves to
+-- the AggregateNode's output column and needs no redirect.
+select wg.a, count(*) as c, row_number() over (order by a) as rn from wg group by a having count(*) > 1;
+→ [{"a":"x","c":2,"rn":1}]
+
+-- HAVING may itself name the grouping key under a spelling its scope does not hold.
+-- Such a reference used to bind to the base-table attribute and read correctly only
+-- because the HAVING filter sits directly on the AggregateNode's yield, where the
+-- representative source row is still published. It now goes through the same
+-- grouping-key redirect as every other post-aggregate clause and reads the
+-- aggregate's own output column, so the predicate stays correct wherever the filter
+-- ends up relative to a buffering operator. Pinned windowed and unwindowed.
+select wg.a, count(*) as c from wg group by a having wg.a = 'x';
+→ [{"a":"x","c":2}]
+
+select wg.a, count(*) as c, row_number() over (order by a) as rn from wg group by a having wg.a = 'x';
+→ [{"a":"x","c":2,"rn":1}]
+
+select wg.a, count(*) as c from wg group by a having upper(wg.a) = 'X';
+→ [{"a":"x","c":2}]
+
+select wg.a, count(*) as c, row_number() over (order by a) as rn from wg group by a having upper(wg.a) = 'X';
+→ [{"a":"x","c":2,"rn":1}]
+
+-- A COMPUTED grouping key written out again in HAVING — matched by the whole-subtree
+-- fingerprint, redirected onto the aggregate's group output column.
+select a || '!' as k, count(*) as c from wg group by a || '!' having a || '!' = 'x!';
+→ [{"k":"x!","c":2}]
+
+select a || '!' as k, count(*) as c, row_number() over (order by a || '!') as rn from wg group by a || '!' having a || '!' = 'x!';
+→ [{"k":"x!","c":2,"rn":1}]
+
+-- A genuinely ungrouped HAVING column keeps its dedicated rejection, windowed or not.
+select wg.a, count(*) as c from wg group by a having b = '1';
+-- error: HAVING references non-grouped column 'b'
+
+select wg.a, count(*) as c, row_number() over (order by a) as rn from wg group by a having b = '1';
+-- error: HAVING references non-grouped column 'b'
+
+-- =============================================================================
+-- The ORDER BY of a grouped query names a grouping key.
+--
+-- The same claim as the SELECT-list cases above, one clause over. A sort key spelled
+-- in a way the projection output scope does not publish — a qualifier the GROUP BY did
+-- not use, a FROM-alias qualifier, the key nested inside a bigger expression, a
+-- computed key written out again — falls through to a BASE-TABLE attribute the grouped
+-- row does not carry. `applyOrderBy` runs the same grouping-key redirect through
+-- `redirectPostAggregate`, gated on "this key actually references a pre-grouping
+-- attribute" (bug-order-by-grouping-key-spelling-breaks-window-query).
+--
+-- Each windowed case is paired with its NON-window twin. The twin answered correctly
+-- before this fix only because its sort consumed the aggregate's yield through
+-- streaming operators, and `emit/aggregate.ts` publishes a representative source row of
+-- the group around each yield. A WindowNode drains its whole source before yielding, so
+-- by the time a sort above it runs every representative row is gone — which is what
+-- turned the mis-binding into "No row context found for column a".
+-- =============================================================================
+
+-- The reported shape: table-qualified sort key, bare GROUP BY, both directions.
+select a, row_number() over (order by a) as rn from wg group by a order by wg.a;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select a, count(*) as c from wg group by a order by wg.a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+select a, row_number() over (order by a) as rn from wg group by a order by wg.a desc;
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+select a, count(*) as c from wg group by a order by wg.a desc;
+→ [{"a":"y","c":1},{"a":"x","c":2}]
+
+-- Qualified through a FROM ALIAS rather than the table name — same base attribute, so
+-- the match is qualifier-independent.
+select w.a, row_number() over (order by a) as rn from wg w group by a order by w.a desc;
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+select w.a, count(*) as c from wg w group by a order by w.a desc;
+→ [{"a":"y","c":1},{"a":"x","c":2}]
+
+-- The grouping key NESTED under a scalar function: the walk recurses, so only the
+-- `wg.a` reference is rewritten and the sort still evaluates `upper()` above it.
+select a, row_number() over (order by a) as rn from wg group by a order by upper(wg.a);
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select a, count(*) as c from wg group by a order by upper(wg.a);
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+select a, row_number() over (order by a) as rn from wg group by a order by upper(wg.a) desc;
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+select a, count(*) as c from wg group by a order by upper(wg.a) desc;
+→ [{"a":"y","c":1},{"a":"x","c":2}]
+
+-- The SELECT list and the ORDER BY both spell the key the same wrong way, so the
+-- select-list redirect and the ORDER BY redirect run on one query.
+select upper(wg.a) as k, row_number() over (order by a) as rn from wg group by a order by upper(wg.a) desc;
+→ [{"k":"Y","rn":2},{"k":"X","rn":1}]
+
+select upper(wg.a) as k, count(*) as c from wg group by a order by upper(wg.a) desc;
+→ [{"k":"Y","c":1},{"k":"X","c":2}]
+
+-- A COMPUTED grouping key repeated verbatim in ORDER BY — matched by the whole-subtree
+-- fingerprint rather than by attribute id.
+select a || '!' as k, row_number() over (order by a || '!') as rn from wg group by a || '!' order by a || '!';
+→ [{"k":"x!","rn":1},{"k":"y!","rn":2}]
+
+select a || '!' as k, count(*) as c from wg group by a || '!' order by a || '!';
+→ [{"k":"x!","c":2},{"k":"y!","c":1}]
+
+-- ...and the same computed key nested inside a bigger ORDER BY expression, which the
+-- whole-expression match cannot see (`upper(a || '!')` is not the key `a || '!'`).
+select a || '!' as k, row_number() over (order by a || '!') as rn from wg group by a || '!' order by upper(a || '!') desc;
+→ [{"k":"y!","rn":2},{"k":"x!","rn":1}]
+
+select a || '!' as k, count(*) as c from wg group by a || '!' order by upper(a || '!') desc;
+→ [{"k":"y!","c":1},{"k":"x!","c":2}]
+
+-- The select list ALIASES the key, so the alias is what the projection scope publishes
+-- and the qualified spelling still has to be redirected.
+select a as k, row_number() over (order by a) as rn from wg group by a order by wg.a desc;
+→ [{"k":"y","rn":2},{"k":"x","rn":1}]
+
+select a as k, count(*) as c from wg group by a order by wg.a desc;
+→ [{"k":"y","c":1},{"k":"x","c":2}]
+
+-- Alongside an aggregate in the select list.
+select wg.a, count(*) as c, row_number() over (order by a) as rn from wg group by a order by wg.a desc;
+→ [{"a":"y","c":1,"rn":2},{"a":"x","c":2,"rn":1}]
+
+select wg.a, count(*) as c from wg group by a order by wg.a desc;
+→ [{"a":"y","c":1},{"a":"x","c":2}]
+
+-- MIXED sort: a window output column (which resolves through the window output scope
+-- and gets no redirect) and a redirected grouping key in the same ORDER BY. The
+-- non-window twin does the same with an aggregate alias.
+select a, row_number() over (order by a) as rn from wg group by a order by rn desc, wg.a;
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+select a, count(*) as c from wg group by a order by c desc, wg.a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+-- A CORRELATED subquery as the sort key, naming the grouping key at depth. Redirected
+-- by the base-attribute rule inside the subquery, so `x` (2 rows) sorts after `y` (1).
+select a, row_number() over (order by a) as rn from wg group by a order by (select count(*) from wg t where t.a = wg.a);
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+select a, count(*) as c from wg group by a order by (select count(*) from wg t where t.a = wg.a);
+→ [{"a":"y","c":1},{"a":"x","c":2}]
+
+-- TWO grouping keys, sorting on the qualified spelling of the second one.
+select a, b, row_number() over (order by a) as rn from wg group by a, b order by wg.b desc;
+→ [{"a":"x","b":"3","rn":2},{"a":"y","b":"2","rn":3},{"a":"x","b":"1","rn":1}]
+
+select a, b, count(*) as c from wg group by a, b order by wg.b desc;
+→ [{"a":"x","b":"3","c":1},{"a":"y","b":"2","c":1},{"a":"x","b":"1","c":1}]
+
+-- HAVING and a redirected ORDER BY on the same query.
+select wg.a, count(*) as c, row_number() over (order by a) as rn from wg group by a having count(*) > 1 order by wg.a desc;
+→ [{"a":"x","c":2,"rn":1}]
+
+select wg.a, count(*) as c from wg group by a having count(*) > 1 order by wg.a desc;
+→ [{"a":"x","c":2}]
+
+-- REGRESSION PINS. The spellings the projection output scope already publishes — the
+-- bare key, an output alias, a window output column, an ordinal — resolve there and
+-- must keep resolving there. The redirect's gate is what protects them: an ungated
+-- fingerprint match would rewrite a correctly-bound `order by a` onto the
+-- AggregateNode's attribute and break a query that worked before this fix.
+select wg.a, row_number() over (order by a) as rn from wg group by a order by a;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select wg.a as k, row_number() over (order by a) as rn from wg group by a order by k;
+→ [{"k":"x","rn":1},{"k":"y","rn":2}]
+
+select a, row_number() over (order by a) as rn from wg group by a order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select wg.a, row_number() over (order by a) as rn from wg group by a order by 1;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+select a, count(*) as c from wg group by a order by 1;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+-- An ORDER BY naming a genuinely UNGROUPED column is now REJECTED at plan time,
+-- windowed and not. It used to be accepted and sorted by an arbitrary representative
+-- row's `b` — a wrong-result bug, and inconsistent with the SELECT list and HAVING,
+-- which already reject ungrouped columns. The finished-plan boundary check
+-- (`assertGroupedPlanCoverage`, see the NOTE at its call in select.ts) is what
+-- rejects it, with the same user-facing message the SELECT list uses.
+select a, row_number() over (order by a) as rn from wg group by a order by b;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a, count(*) as c from wg group by a order by b;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A COMPUTED grouping key is matched by the whole expression's TEXT, so a qualifier
+-- the GROUP BY did not use makes it a different expression — and what is left is a
+-- bare reference to the ungrouped `a`. (A bare-column key is matched by attribute id
+-- instead, which is why `group by a order by wg.a` further down works under any
+-- qualifier.) The SELECT list has always rejected this spelling; ORDER BY used to
+-- accept it and sort by an arbitrary representative row, so the pin below is the
+-- ORDER BY half becoming consistent with the select-list half above it. Tracked as
+-- backlog/debt-group-key-match-by-attribute-identity.
+select upper(a) as k, count(*) as c from wg group by upper(a) order by upper(wg.a);
+-- error: Column 'wg.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+select upper(wg.a) as k, count(*) as c from wg group by upper(a);
+-- error: Column 'wg.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Control: one spelling on both sides matches, windowed and not.
+select upper(a) as k, count(*) as c from wg group by upper(a) order by upper(a);
+→ [{"k":"X","c":2},{"k":"Y","c":1}]
+
+select upper(a) as k, row_number() over (order by upper(a)) as rn from wg group by upper(a);
+→ [{"k":"X","rn":1},{"k":"Y","rn":2}]
+
+-- The `preWindowSort` placement (an ORDER BY column absent from the select list gets
+-- its sort BELOW the window projection) with a QUALIFIED spelling of a grouping key:
+-- that sort still sits ABOVE the AggregateNode, so its key is redirected onto the
+-- aggregate's own output column like every other post-aggregate sort key. (The
+-- window's own ordering wins on output — pre-existing preWindowSort semantics; what
+-- these pin is that the qualified key plans and evaluates instead of dying.)
+select a, row_number() over (order by a) as rn from wg group by a, b order by wg.b;
+→ [{"a":"x","rn":1},{"a":"x","rn":2},{"a":"y","rn":3}]
+
+select a, row_number() over (order by a) as rn from wg group by a, b order by wg.b desc;
+→ [{"a":"x","rn":1},{"a":"x","rn":2},{"a":"y","rn":3}]
+
+-- The EARLY ORDER BY placement (taken when ORDER BY introduces an aggregate the
+-- select list does not have) alongside a qualified grouping-key spelling: both keys
+-- of one sort, one resolved through the aggregates context, one redirected.
+select a from wg group by a order by count(*) desc, wg.a;
+→ [{"a":"x"},{"a":"y"}]
+
+select a from wg group by a order by count(*), wg.a;
+→ [{"a":"y"},{"a":"x"}]
+
+-- The grouping key is NOT in the select list, so no projection output column carries it
+-- and the redirect is the only thing that can bind the sort key. A non-column ORDER BY
+-- expression, so `preWindowSort` does not divert it either — this reaches the redirect
+-- and reads the AggregateNode's group column through the WindowNode's passthrough.
+select count(*) as c, row_number() over (order by count(*)) as rn from wg group by a order by upper(wg.a) desc;
+→ [{"c":1,"rn":1},{"c":2,"rn":2}]
+
+select count(*) as c from wg group by a order by upper(wg.a) desc;
+→ [{"c":1},{"c":2}]
+
+-- DISTINCT sits between the projection and the sort, so the redirected key is read
+-- through one more operator than the cases above.
+select distinct a, row_number() over (order by a) as rn from wg group by a order by wg.a desc;
+→ [{"a":"y","rn":2},{"a":"x","rn":1}]
+
+select distinct a, count(*) as c from wg group by a order by wg.a desc;
+→ [{"a":"y","c":1},{"a":"x","c":2}]
+
+-- =============================================================================
+-- SELECT LIST of a grouped query, continued.
+-- =============================================================================
+
+-- An UNGROUPED select-list column is still rejected at plan time, with the same
+-- message and the same wording, window function or not. `validateAggregateProjections`
+-- runs on the pre-aggregate projections and never sees the redirect.
+select wg.b, row_number() over (order by a) as rn from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select wg.b from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- A SUBQUERY in the select list whose text spells the grouping key but resolves to
+-- its OWN column keeps the inner meaning: inside a subquery the fingerprint rule is
+-- guarded by "does this subtree read only pre-grouping columns of THIS query", and
+-- `t.a` is the subquery's. So the predicate is the tautology `t.a = t.a` and every
+-- group counts all 3 rows.
+select a, (select count(*) from wg t where t.a = a) as c from wg group by a order by a;
+→ [{"a":"x","c":3},{"a":"y","c":3}]
+
+select a, (select count(*) from wg t where t.a = a) as c, row_number() over (order by a) as rn from wg group by a order by a;
+→ [{"a":"x","c":3,"rn":1},{"a":"y","c":3,"rn":2}]
+
+-- A genuinely CORRELATED select-list subquery naming the grouping key is redirected
+-- through the subquery, by attribute id, at any depth — it used to die with an
+-- internal "No row context found for column a".
+select a, (select count(*) from wg t where t.a = wg.a) as c from wg group by a order by a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+select a, (select t.b from wg t where t.a = wg.a and t.b = '1') as c, row_number() over (order by a) as rn
+from wg group by a order by rn;
+→ [{"a":"x","c":"1","rn":1},{"a":"y","c":null,"rn":2}]
+
+-- A correlated subquery reading a genuinely UNGROUPED column of this query is
+-- rejected at plan time by the finished-plan boundary check — it used to plan and
+-- then read an arbitrary representative row (or die at run time with an internal
+-- "No row context found" error once a WindowNode sat in between). The subquery's own
+-- `t.b` is a different attribute instance and stays legal; only the correlated
+-- `wg.b` is flagged.
+select a, (select count(*) from wg t where t.b = wg.b) as c from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a, (select count(*) from wg t where t.b = wg.b) as c, row_number() over (order by a) as rn from wg group by a;
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a, count(*) as c from wg group by a order by (select count(*) from wg t where t.b = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- The check walks the finished PLAN, not any one clause, so the other correlated
+-- shapes reject identically: an EXISTS and an IN, each correlated on the ungrouped
+-- `wg.b`. (HAVING's own bare-column rejection never sees these — its check does not
+-- descend into a subquery.)
+select a, count(*) as c from wg group by a having exists (select 1 from wg t where t.a = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a from wg group by a having a in (select t.a from wg t where t.b = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Control: the same two shapes correlated on the GROUPING KEY are redirected and run.
+select a, count(*) as c from wg group by a having exists (select 1 from wg t where t.a = wg.a) order by wg.a;
+→ [{"a":"x","c":2},{"a":"y","c":1}]
+
+select a from wg group by a having a in (select t.a from wg t where t.a = wg.a) order by wg.a;
+→ [{"a":"x"},{"a":"y"}]
+
+-- =============================================================================
+-- A WINDOW RESULT COLUMN IS ADDRESSED BY ATTRIBUTE IDENTITY, NOT POSITION.
+-- Regression for bug-window-column-read-by-position-hits-wrong-row: the window
+-- phase used to hand the projection a POSITIONAL read of the WindowNode's row,
+-- which silently read whatever row context was newest. Whenever decorrelation
+-- placed a join between the WindowNode and its projection, the window column
+-- came back as a verbatim copy of the subquery's value. Non-numeric text values
+-- ('p','q','r') on purpose: numeric-looking text picks up numeric affinity on
+-- the way through and muddies WHICH column is wrong.
+-- =============================================================================
+create table wsq (a text, b text);
+insert into wsq values ('x','p'),('y','q'),('x','r');
+
+-- Correlated scalar-aggregate subquery (routes through rule-scalar-agg-decorrelation,
+-- which puts a grouped LEFT JOIN above the WindowNode) alongside each window shape.
+-- `n` used to come back as a copy of `c`.
+select k, (select min(t.b) from wsq t where t.a = k) as c, count(*) over () as n from (select a as k from wsq) group by k;
+→ [{"k":"x","c":"p","n":2},{"k":"y","c":"q","n":2}]
+
+select k, (select min(t.b) from wsq t where t.a = k) as c, row_number() over (order by k) as rn from (select a as k from wsq) group by k;
+→ [{"k":"x","c":"p","rn":1},{"k":"y","c":"q","rn":2}]
+
+-- The desc spelling additionally needs the window's honest ordering advertisement
+-- (bug-window-node-advertises-source-row-order) so the merge join above it does
+-- not drop rows.
+select k, (select min(t.b) from wsq t where t.a = k) as c, row_number() over (order by k desc) as rn from (select a as k from wsq) group by k;
+→ [{"k":"y","c":"q","rn":1},{"k":"x","c":"p","rn":2}]
+
+-- The same three shapes with an EXISTS and with an IN correlated subquery, which
+-- route through rule-subquery-decorrelation instead.
+select a, exists (select 1 from wsq t where t.a = wsq.a and t.b = 'p') as e, count(*) over () as n from wsq group by a;
+→ [{"a":"x","e":true,"n":2},{"a":"y","e":false,"n":2}]
+
+select a, exists (select 1 from wsq t where t.a = wsq.a and t.b = 'p') as e, row_number() over (order by a) as rn from wsq group by a;
+→ [{"a":"x","e":true,"rn":1},{"a":"y","e":false,"rn":2}]
+
+select a, exists (select 1 from wsq t where t.a = wsq.a and t.b = 'p') as e, row_number() over (order by a desc) as rn from wsq group by a;
+→ [{"a":"y","e":false,"rn":1},{"a":"x","e":true,"rn":2}]
+
+select a, 'p' in (select t.b from wsq t where t.a = wsq.a) as i, count(*) over () as n from wsq group by a;
+→ [{"a":"x","i":true,"n":2},{"a":"y","i":false,"n":2}]
+
+select a, 'p' in (select t.b from wsq t where t.a = wsq.a) as i, row_number() over (order by a) as rn from wsq group by a;
+→ [{"a":"x","i":true,"rn":1},{"a":"y","i":false,"rn":2}]
+
+select a, 'p' in (select t.b from wsq t where t.a = wsq.a) as i, row_number() over (order by a desc) as rn from wsq group by a;
+→ [{"a":"y","i":false,"rn":1},{"a":"x","i":true,"rn":2}]
+
+-- UNGROUPED windowed query with a correlated subquery — was already correct (the
+-- streaming window path keeps the window's own row newest); regression guard.
+select a, (select min(t.b) from wsq t where t.a = wsq.a) as c, row_number() over (order by a) as rn from wsq order by rn;
+→ [{"a":"x","c":"p","rn":1},{"a":"x","c":"p","rn":2},{"a":"y","c":"q","rn":3}]
+
+-- Two window functions with DIFFERENT specifications alongside the decorrelated
+-- subquery, so a mis-addressed read cannot be masked by both columns holding the
+-- same value.
+select k, (select min(t.b) from wsq t where t.a = k) as c, count(*) over () as n, row_number() over (order by k) as rn from (select a as k from wsq) group by k;
+→ [{"k":"x","c":"p","n":2,"rn":1},{"k":"y","c":"q","n":2,"rn":2}]
+
+-- Two window functions with the SAME specification now genuinely share one
+-- WindowNode; each must still resolve to its own distinct output column — the
+-- case the old source-location accident in the spec grouping was protecting.
+select a, row_number() over (order by a) as rn, count(*) over (order by a) as rc from wsq group by a;
+→ [{"a":"x","rn":1,"rc":1},{"a":"y","rn":2,"rc":2}]
+
+-- Same-NAME functions sharing one specification (and so one WindowNode) keep
+-- their own argument expressions.
+select b, sum(length(b)) over (order by b) as s1, sum(length(b) * 10) over (order by b) as s2 from wsq order by b;
+→ [{"b":"p","s1":1,"s2":10},{"b":"q","s1":2,"s2":20},{"b":"r","s1":3,"s2":30}]
+
+-- A PARTITIONED window beside the decorrelated subquery: the partitioned buffered
+-- path emits whole partitions in first-seen order and advertises neither ordering
+-- nor monotonicity, so the join above it sees a different shape than the sorted
+-- cases above.
+select a, (select min(t.b) from wsq t where t.a = wsq.a) as c, count(*) over (partition by a) as n from wsq group by a;
+→ [{"a":"x","c":"p","n":1},{"a":"y","c":"q","n":1}]
+
+-- Two functions with ARGUMENTS sharing one specification (so one WindowNode, whose
+-- per-function argument arrays must stay aligned with its output columns).
+select a, (select min(t.b) from wsq t where t.a = wsq.a) as c, lag(a) over (order by a) as lg, lead(a) over (order by a) as ld from wsq group by a;
+→ [{"a":"x","c":"p","lg":null,"ld":"y"},{"a":"y","c":"q","lg":"x","ld":null}]
+
+-- A filter over a window output column through a subquery. The filter references
+-- a real window attribute the window's SOURCE does not carry, so the availability
+-- check must keep it above the WindowNode — a future pushdown rule that loses
+-- this returns [{"a":"x",...}] too.
+select * from (select a, row_number() over (order by a) as rn from wsq group by a) where rn > 1;
+→ [{"a":"y","rn":2}]
+
+drop table wsq;
+
+-- Composition: the fixed shape as a subquery source, inside a CTE, and as a
+-- `union all` arm.
+select * from (select wg.a, row_number() over (order by a) as rn from wg group by a) z order by rn;
+→ [{"a":"x","rn":1},{"a":"y","rn":2}]
+
+with q as (select wg.a, row_number() over (order by a) as rn from wg group by a)
+select * from q where rn > 1;
+→ [{"a":"y","rn":2}]
+
+select wg.a as k, row_number() over (order by a) as rn from wg group by a
+union all select b, 9 from wg order by k, rn;
+→ [{"k":"1","rn":9},{"k":"2","rn":9},{"k":"3","rn":9},{"k":"x","rn":1},{"k":"y","rn":2}]
+
+-- An EMPTY grouped, windowed query: no group ever yields, so no representative
+-- source row is ever published. Exercises the path with the fallback absent.
+delete from wg;
+select wg.a, row_number() over (order by a) as rn from wg group by a;
+→ []
+
+drop table wg;
+
+-- A NULL grouping key forms one group of its own and must appear exactly once.
+create table wn (id integer primary key, a text null);
+insert into wn values (1,'x'),(2,null),(3,'x');
+
+select wn.a, row_number() over (order by a) as rn from wn group by a order by rn;
+→ [{"a":null,"rn":1},{"a":"x","rn":2}]
+
+select wn.a, count(*) as c from wn group by a order by c;
+→ [{"a":null,"c":1},{"a":"x","c":2}]
+
+drop table wn;
+
+-- Two grouping keys sharing a bare name across a join. Their QUALIFIED names are
+-- registered by the aggregate output scope, so those references resolve there and
+-- never reach the redirect; the bare name stays ambiguous. Pinned windowed and
+-- unwindowed so the redirect is proved not to have disturbed the ambiguity.
+create table ji (id text, v text);
+create table jc (id text, w text);
+insert into ji values ('k1','a'),('k2','b');
+insert into jc values ('k1','p'),('k2','q');
+
+select i.id, c.id, row_number() over (order by i.id) as rn
+from ji i join jc c on i.id = c.id group by i.id, c.id order by rn;
+→ [{"id":"k1","id:1":"k1","rn":1},{"id":"k2","id:1":"k2","rn":2}]
+
+select i.id, c.id from ji i join jc c on i.id = c.id group by i.id, c.id order by 1;
+→ [{"id":"k1","id:1":"k1"},{"id":"k2","id:1":"k2"}]
+
+select id, row_number() over (order by i.id) as rn
+from ji i join jc c on i.id = c.id group by i.id, c.id;
+-- error: ambiguous column name: id
+
+drop table ji;
+drop table jc;
+
+-- =============================================================================
+-- `*` in a window query.
+--
+-- The window phase's projection used to walk the AST select list and handle only
+-- non-star entries, so a `*` was skipped outright and its columns never reached
+-- the output. The projection is now the query's ONE select-list projection, with
+-- stars already expanded, so a star is an ordinary entry.
+--
+-- Column NAMES and ORDER are asserted in test/plan/grouped-projection-shape.spec.ts
+-- (row objects compare key-order-insensitively here); this file pins the values.
+-- =============================================================================
+
+create table sw (v integer primary key, g text);
+insert into sw values (1,'a'),(2,'b');
+
+-- Star before the window column.
+select *, row_number() over (order by v) as w from sw order by v;
+→ [{"v":1,"g":"a","w":1},{"v":2,"g":"b","w":2}]
+
+-- Star after the window column.
+select row_number() over (order by v) as w, * from sw order by v;
+→ [{"w":1,"v":1,"g":"a"},{"w":2,"v":2,"g":"b"}]
+
+-- A named column repeated by a later star is disambiguated as `v:1`.
+select v, row_number() over (order by v) as w, * from sw order by w;
+→ [{"v":1,"w":1,"v:1":1,"g":"a"},{"v":2,"w":2,"v:1":2,"g":"b"}]
+
+-- Qualified star.
+select sw.*, row_number() over (order by v) as w from sw order by v;
+→ [{"v":1,"g":"a","w":1},{"v":2,"g":"b","w":2}]
+
+-- A positional ORDER BY over a star-bearing window query binds the window column
+-- (position 3 = the column after the two star columns).
+select *, row_number() over (order by v) as w from sw order by 3 desc;
+→ [{"v":2,"g":"b","w":2},{"v":1,"g":"a","w":1}]
+
+-- DISTINCT over a window column.
+select distinct row_number() over (order by v) as w from sw order by w;
+→ [{"w":1},{"w":2}]
+
+-- An UNALIASED window column keeps its authored expression as its output name,
+-- like every other unaliased select-list column, rather than the name of the
+-- window-output column the rewrite substitutes in.
+select row_number() over (order by v) from sw order by v;
+→ [{"row_number() over (order by v)":1},{"row_number() over (order by v)":2}]
+
+select v, 1000 - row_number() over (order by v) from sw order by v;
+→ [{"v":1,"1000 - row_number() over (order by v)":999},{"v":2,"1000 - row_number() over (order by v)":998}]
+
+drop table sw;
+
+-- =============================================================================
+-- The window node's advertised row order must describe what the window emitter
+-- actually yields (bug-window-node-advertises-source-row-order). A window that
+-- sorts its own rows used to keep advertising the SOURCE's order, and a merge
+-- join above it walked the reordered stream as if it were still in that order —
+-- silently dropping every row after the first mismatch.
+-- =============================================================================
+
+create table wmj (a text, b text);
+insert into wmj values ('x','p'),('y','q'),('x','r'),('z','s');
+
+-- The repro: `order by a desc` inside the window reverses the grouped rows, so
+-- the join above it must not assume ascending `a`. All four rows must survive.
+select z.a, z.rn, w2.b
+from (select a, row_number() over (order by a desc) as rn from wmj group by a) z
+join wmj w2 on w2.a = z.a
+order by z.a, w2.b;
+→ [{"a":"x","rn":3,"b":"p"},{"a":"x","rn":3,"b":"r"},{"a":"y","rn":2,"b":"q"},{"a":"z","rn":1,"b":"s"}]
+
+-- The ascending twin, which was already correct and must stay correct: here the
+-- window's emit order genuinely does match the source's.
+select z.a, z.rn, w2.b
+from (select a, row_number() over (order by a) as rn from wmj group by a) z
+join wmj w2 on w2.a = z.a
+order by z.a, w2.b;
+→ [{"a":"x","rn":1,"b":"p"},{"a":"x","rn":1,"b":"r"},{"a":"y","rn":2,"b":"q"},{"a":"z","rn":3,"b":"s"}]
+
+-- Same shape as a LEFT JOIN: a lost match would show up as NULL fill rather
+-- than as a missing row.
+select z.a, z.rn, w2.b
+from (select a, row_number() over (order by a desc) as rn from wmj group by a) z
+left join wmj w2 on w2.a = z.a
+order by z.a, w2.b;
+→ [{"a":"x","rn":3,"b":"p"},{"a":"x","rn":3,"b":"r"},{"a":"y","rn":2,"b":"q"},{"a":"z","rn":1,"b":"s"}]
+
+drop table wmj;
+
+-- A PARTITION BY window buffers the source and re-emits it a whole partition at
+-- a time, so the scan's key order does NOT survive it. The outer ORDER BY must
+-- be honoured rather than elided against the source's ordering.
+create table wpo (k integer primary key, g text, v integer);
+insert into wpo values (1,'a',10),(2,'b',20),(3,'a',30),(4,'b',40);
+
+select k, g, sum(v) over (partition by g) as s from wpo order by k;
+→ [{"k":1,"g":"a","s":40},{"k":2,"g":"b","s":60},{"k":3,"g":"a","s":40},{"k":4,"g":"b","s":60}]
+
+-- Same, joined against the partition column: the join above the partitioned
+-- window may not assume the window preserved the scan's order either.
+select w.k, w.s, o.g
+from (select k, g, sum(v) over (partition by g) as s from wpo) w
+join wpo o on o.k = w.k
+order by w.k;
+→ [{"k":1,"s":40,"g":"a"},{"k":2,"s":60,"g":"b"},{"k":3,"s":40,"g":"a"},{"k":4,"s":60,"g":"b"}]
+
+-- An unpartitioned window with a descending ORDER BY, consumed by an outer
+-- ascending ORDER BY: the outer sort must survive, since the window emits desc.
+select k, v, row_number() over (order by v desc) as rn from wpo order by k;
+→ [{"k":1,"v":10,"rn":4},{"k":2,"v":20,"rn":3},{"k":3,"v":30,"rn":2},{"k":4,"v":40,"rn":1}]
+
+drop table wpo;