Company or project name

ClickHouse

Use case

1. Query constructors, to allow users to customize various parts of the query.
2. Possibility to implement query rewrite rules by capturing and reusing certain parts of AST.
3. Block lists that work on the AST level rather than with regexps.

Describe the solution you'd like

Introduce new types of substitutions, e.g.,

SELECT {output:ExpressionList}
FROM table
WHERE is_robot AND {condition:Expression}

Parameters of these types will be parsed from a string with the corresponding ParserExpression, ParserExpressionList.

Describe alternatives you've considered

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Additional context

We may want to prevent recursive parameters inside Expression and ExpressionList.

We may want to allow flattening of ExpressionList as an element of ExpressionList, to enable queries like SELECT a, {expr:ExpressionList} ...

Parameterized views should accept these values directly, without parsing from a string. For example, with optional parentheses:

SELECT * FROM view(expr = (x = 2 AND y = 3))