feat(clickhouse): Add support for APPLY query modifier

[VaggelisD]

Fixes #4139

Clickhouse supports the APPLY query modifier:

SELECT <expr> APPLY( <func> ) FROM [db.]table_name

Although apply is still a valid alias, we shouldn't parse it as such if it's accompanied by an L_PAREN as is the case here, thus the overriden _parse_alias() in Clickhouse:

clickhouse> select 1 apply;

   ┌─apply─┐
1. │     1 │
   └───────┘

clickhouse> with t as (Select 1 as col) select COLUMNS('col') apply(sum) from t;

   ┌─sum(col)─┐
1. │        1 │
   └──────────┘

Note that APPLY can be chained, as is shown in the docs & relevant test case

Docs

Clickhouse APPLY modifier

[tobymao]

is this the right approach? should we treat this similarly to window functions?

[VaggelisD]

@tobymao Clickhouse is a bit lax with the rules, the grammar etc so I struggled a bit to not break any functionality as with the apply alias vs modifier. Regarding window functions, which part would that be, reusing _parse_query_modifiers()?

Note that APPLY comes before the query's FROM so we must either parse it early on it's own (the approach here) or add it in QUERY_MODIFIER_PARSERS and call _parse_query_modifiers() in the place of my current while loop afaict.

[tobymao]

is this section tested? how is it different from the parse alias section?

[VaggelisD]

In _parse_alias(), we don't want to parse an actual alias if we match "APPLY", "(".

In _parse_select(), we want to match the APPLY(...) clause between the projection list and the FROM clause.

I can add more tests that check that e.g. SELECT 1 apply produces an exp.Alias clause