Found in the #539 review.
Problem
SELECT a.k, b.k FROM a JOIN b ON a.id = b.id ORDER BY b.k used to sort by a.k without any error. The SQL lowering emits the Project above the join with qualifier: None, so its output schema loses each column's source table. The resolver then failed to find b.k by (table, name) and fell back to the first column named k.
Status
#539 makes this fallback safe: it now applies only when exactly one column has that name. Otherwise resolution fails. The query above is now rejected instead of being lowered wrongly.
Follow-up
Make such queries lower correctly. The obstacle is that the IR's Project has a single qualifier for all of its output columns (#573 §4.2.2 relies on this), so a pass-through column cannot keep its own source table. Options:
- per-column qualifiers on
Project;
- resolving
ORDER BY against the pre-projection scope in the frontend.
🤖 Generated with Claude Code
https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW
Found in the #539 review.
Problem
SELECT a.k, b.k FROM a JOIN b ON a.id = b.id ORDER BY b.kused to sort bya.kwithout any error. The SQL lowering emits theProjectabove the join withqualifier: None, so its output schema loses each column's source table. The resolver then failed to findb.kby(table, name)and fell back to the first column namedk.Status
#539 makes this fallback safe: it now applies only when exactly one column has that name. Otherwise resolution fails. The query above is now rejected instead of being lowered wrongly.
Follow-up
Make such queries lower correctly. The obstacle is that the IR's
Projecthas a singlequalifierfor all of its output columns (#573 §4.2.2 relies on this), so a pass-through column cannot keep its own source table. Options:Project;ORDER BYagainst the pre-projection scope in the frontend.🤖 Generated with Claude Code
https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW