Decide how to handle Aggregate function combinators

[theory]

ClickHouse Aggregate function combinators allow users to append suffixes to aggregate functions to change behaviors. pg_clickhouse does this some automatically already:

• To convert filtered aggregates to addNameIf()
• To append Merge to aggregates on AggregateFunction columns

ClickHouse also provides similar combinators for regular functions, as in type conversion functions each having OrNull, OrDefault, and OrZero variants.

It would be nice not to have to implement all of these variants in pg_clickhouse. Would it be possible to somehow annotate them in some other way, in SQL, such that they could be recognized and applied (if they're not automatically applied for some other reason)? Some random ideas:

• Provide functions just for the combinators, e.g., orZero(), so they could be called as orZero(toUInt8()). Downsides: Need variants that return every data type, and the rewriter must set a flag so the nested function can be rewritten with the combinator.
• Provide functions for each combinator that could be passed as the first argument to another function, e.g., toUInt8(orZero())`. Downside: changes the possible parameter list for every function
• Make up some syntax or use the existing syntax but then hook into the Postgres Parser to find them and to rewrite the plan nodes as appropriate. Postgres won't recognize toUInt8OrNull() if only toUInt8() is defined, but perhaps we can hook into the parser to recognize the syntax and accept it?