REPL JOIN + ORDER BY fails: qualifier lost in AST→SQL reconstruction ('Ambiguous column')

[fupelaqu]

Symptom

Through the REPL (extension path), any cross-index JOIN with an ORDER BY fails:

SELECT e.name, e.salary, d.dept_name
FROM jdbc_join_emp e JOIN jdbc_join_dept d ON e.dept_id = d.dept_id
ORDER BY e.salary DESC;
-- ❌ Ambiguous column 'salary' in JOIN query — qualify with table alias (e.g., e.salary)

The alias IS qualified in the user's SQL. Aliasing the projection (e.salary AS salary … ORDER BY salary) fails identically. Verified live on ES 8.18.3 with cli 0.20.0 + arrow-extensions 0.2.0 (JOIN extension engaged — same query without ORDER BY returns correct rows).

Root cause hypothesis

The REPL path goes run(sql) → Parser → SingleSearch → JoinExtension, which reconstructs SQL from the AST for the DuckDB planner. The parser normalizes ORDER BY e.salary to sort field salary (ES sort needs no qualifier — see the gateway log: … ORDER BY salary DESC), so the reconstructed SQL reaches the join planner unqualified and its ambiguity check rejects it. JDBC is unaffected (raw SQL passthrough — 62/62 integration tests green).

Impact

Breaks the exact demo query in the R1 launch materials (LinkedIn demo teaser / blog examples use ORDER BY e.salary DESC in the REPL). Workaround for demos: drop ORDER BY, or order client-side.

Fix directions

Either preserve the table-alias qualifier in the SQL AST's OrderBy rendering (sql module), or resolve unqualified ORDER BY columns against the join output schema in the arrow-ext planner before the ambiguity check.

Found during the R1 installer E2E verification (PR #156, arrow#125).