A way to parameterize VIEWs using WITH? - clickhouse

Question

I find that I write a lot of very long queries, where I copy paste subqueries. I've been looking for an idiomatic way to increase code reuse. I am aware of CREATE VIEW. However, I do use the WITH statement a lot. I am aware that WHERE clauses are pushed down into the view. However, I am not aware of a solution that would allow me to parameterize GROUP BY and ORDER BY statements. Let me give you an example:
WITH
'America/New_York' AS tz,
toDateTime('2000-10-02 00:00:00', tz) AS start_dt,
toDateTime('2001-03-10 00:00:00', tz) AS end_dt,
INTERVAL 1 DAY AS interval_param,
'1hour` AS frequency_param
SELECT
ts,
argMinMerge(src.price) AS first,
argMaxMerge(src.price) AS last,
toTimeZone(min(src.ts), tz) AS first_ts,
toTimeZone(max(src.ts), tz) AS last_ts
FROM some_db.some_table AS src
WHERE src.frequency = frequency_param
AND toTimeZone(src.ts, tz) >= start_dt
AND toTimeZone(src.ts, tz) < end_dt
GROUP BY toStartOfInterval(src.ts, interval_param, tz) AS ts
ORDER BY ts
In this example I define some static parameters within the WITH clause which are then used in SELECT, WHERE, and GROUP BY clauses. It's very convenient to have all "input parameters" at the top in the WITH clause. As far as I know I will not be able to create a VIEW that would encapsulate this entire query.
Is the below the best I could do?
CREATE VIEW my_query_as_view AS
SELECT
ts,
argMinMerge(src.price) AS first,
argMaxMerge(src.price) AS last,
toTimeZone(min(src.ts), tz) AS first_ts,
toTimeZone(max(src.ts), tz) AS last_ts
FROM some_db.some_table AS src
WITH
'America/New_York' AS tz,
toDateTime('2000-10-02 00:00:00', tz) AS start_dt,
toDateTime('2001-03-10 00:00:00', tz) AS end_dt,
INTERVAL 1 DAY AS interval_param,
'1hour` AS frequency_param
SELECT * FROM my_query_as_view
WHERE src.frequency = frequency_param
AND toTimeZone(src.ts, tz) >= start_dt
AND toTimeZone(src.ts, tz) < end_dt
GROUP BY toStartOfInterval(src.ts, interval_param, tz) AS ts
ORDER BY ts
I am not sure this is any better. The problem becomes worse when I start nesting 3, 4, or even more queries.