[Refactor] New Tests for Query Parser/Formatter

[HazelYuAhiru]

Overview

Add tests for the query parser. After this PR, the reviewed test cases can be copied to the formatter and end-to-end test files.

Code Changes

• Added 40 new test cases in test_query_parser.py.

Issues Detected

• Missing AST support: Type/Special keywords (TEXT, INTEGER, DATE, NULL) are FunctionNodes; consider a keyword/node type (tests 1–5, 41-43).
• Missing AST support: UNION not supported (queries 15, 29, 32).
• Missing AST support: DISTINCT(tests 11, 18, 35)/DISTINCT ON(test 40) not supported.
• Parser Issue: IS NULL emitted as FunctionNode("MISSING"); desired form is OperatorNode(col, "IS", [NULL]) (test 41).
• Parser Issue: Arithmetic (+, -, , /) emitted as FunctionNode ADD/SUB/MUL/DIV; could map to OperatorNode (tests 27, 42).
• Parser Issue: the right-hand side of IN should be a list of literals, not one LiteralNode whose value is a list. (test 20)

Design Questions

• New node for CASE: CASE currently is under FunctionNode; consider a dedicated CaseNode? (test 31)
• Special SQL cases:
  • GROUP BY 1, 2 handling to be confirmed. Currently are literals 1, 2; consider replace as column refs? (test 43)
  • INTERVAL handling to be confirmed (test 42, 43).

[Copilot]

Pull request overview

This pull request adds 40 new test cases for the query parser to document expected AST representations and known parser limitations. The tests cover various SQL constructs including CAST operations, self-joins, subqueries, complex WHERE conditions, aggregations with CASE statements, and advanced features like DISTINCT and UNION.

Changes:

• Added 40 new test functions in test_query_parser.py, documenting expected AST structures for real-world SQL queries
• Included TODO comments throughout the tests identifying known parser limitations that need to be addressed (e.g., TYPE keywords as FunctionNodes, missing UNION support, missing DISTINCT support)
• Most test assertions are commented out since many features are not yet fully supported by the parser

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Inconsistent representation of IN operator with list values. Lines 1413 and 1436 wrap the list in LiteralNode (e.g., LiteralNode(["FCM", "ONE_SIGNAL"])), but lines 1423-1431 use a plain Python list (e.g., [LiteralNode(0), LiteralNode(1), ...]). According to OperatorNode's signature, the _right parameter must be a Node. Additionally, LiteralNode's type hint indicates _value should be str|int|float|bool|datetime|None, which doesn't include list. For consistency, choose one approach: either wrap all IN lists in LiteralNode (and update LiteralNode's type hint to include list), or use a dedicated structure for representing IN lists.

Suggested change

	[
	LiteralNode(0),
	LiteralNode(1),
	LiteralNode(2),
	LiteralNode(3),
	LiteralNode(4),
	LiteralNode(5),
	LiteralNode(6),
	],
	LiteralNode([0, 1, 2, 3, 4, 5, 6]),

[HazelYuAhiru]

I think the old way semantically makes more sense. I will modify Lines 1413 and 1436 instead.