Should

OVER

be registered as a SQL function? Currently

Expr::Over

is implemented as

Over(WindowExpr, window::WindowSpec)

where

WindowExpr

is things like

Agg(AggExp)

,

RowNumber

,

Offset(ExprRef, i64, Option<ExprRef>)

(lag/lead), etc. And would window functions need a new planning method like

plan_aggregate_query

or something? And how is the below SQL expression parsed currently?

SELECT 
            category, 
            value, 
            ROW_NUMBER() OVER(
                PARTITION BY category 
                ORDER BY value
            ) AS row_num 
        FROM test_data
        ORDER BY category, value

It looks like

current_plan: LogicalPlanBuilder { plan: Project(Project { plan_id: None, input: Sort(Sort { plan_id: None, input: SubqueryAlias(SubqueryAlias { plan_id: None, input: Source(Source { plan_id: None, output_schema: Schema { fields: [Field { name: "category", dtype: Utf8, metadata: {} }, Field { name: "value", dtype: Int64, metadata: {} }], name_to_indices: {"category": [0], "value": [1]} }, source_info: InMemory(InMemoryInfo { source_schema: Schema { fields: [Field { name: "category", dtype: Utf8, metadata: {} }, Field { name: "value", dtype: Int64, metadata: {} }], name_to_indices: {"category": [0], "value": [1]} }, cache_key: "411f41c750be4ba795c2607d42c0f8ab", cache_entry: Some(Python(Py(0x11d85a6d0))), num_partitions: 1, size_bytes: 144, num_rows: 8, clustering_spec: None, source_stage_id: None }), stats_state: NotMaterialized }), name: "test_data" }), sort_by: [Column(Resolved(Basic("category"))), Column(Resolved(Basic("value")))], descending: [false, false], nulls_first: [false, false], stats_state: NotMaterialized }), projection: [Column(Resolved(Basic("category"))), Column(Resolved(Basic("value"))), Alias(WindowFunction(RowNumber), "row_num")], projected_schema: Schema { fields: [Field { name: "category", dtype: Utf8, metadata: {} }, Field { name: "value", dtype: Int64, metadata: {} }, Field { name: "row_num", dtype: UInt64, metadata: {} }], name_to_indices: {"row_num": [2], "value": [1], "category": [0]} }, stats_state: NotMaterialized }), config: None }

But I'm unclear where

OVER

is interpreted.

• SQLFunctions is for scalar functions like

abs

or

upper

whereas window functions are their own class of functions. • Agg functions are in their own class which is distinct from the window function class. • Yes, you will need to add a planner method specific for window functions. • An easy way to see what the AST looks like is to write a rust unit test, run the test query through sqlparser-rs and use

dbg!