add filter clause support at AggregateFunctionBuilder.

[igalklebanov]

brought up by @thelinuxlich on discord.

Postgres [1] [2] & SQLite support filter clause when using aggregate functions, with syntax as follows:

aggregate_function(...) [filter(where ...)] [over(...)]

Its a simple alternative to using case...when...then...end inside the aggregate function.

This PR adds filterWhere, filterWhereExists, filterWhereNotExists, filterWhereRef, orFilterWhere, orFilterWhereExists, orFilterWhereNotExists & orFiltereWhereRef to AggregateFunctionBuilder.

---

• implement.
• unit tests.
• typings tests.
• ts docs.

---

Some things to consider..

• since where is nested in filter, maybe its more intuitive and future-proof to make a FilterBuilder that implements WhereInterface, and make filter accept a FilterBuilderCallback instead of acting as the where itself?
• maybe we should rename filter to filterWhere to not hide where from caller? went with it, feels more aligned with Kysely's API philosophy.
• since filter clause is a thing, maybe we should rename the existing FilterNode, parsers, etc and introduce a new FilterNode?

[koskimas]

since where is nested in filter, maybe its more intuitive and future-proof to make a FilterBuilder that implements WhereInterface, and make filter accept a FilterBuilderCallback instead of acting as the where itself?

🤔 Maybe. On the other hand, too many nested callbacks starts to look messy.

since filter clause is a thing, maybe we should rename the existing FilterNode, parsers, etc and introduce a new FilterNode?

We could go towards more generic ASTish nodes and rename it to BinaryOperationNode and also have UnaryOperationNode for exists etc. unary operations. We'll need these anyway if we implement the full expression builder at some point. What do you think?

We already have these "semantic" parent nodes like WhereNode and OnNode so we wouldn't lose any "transformability".

I originally called the node tree AST but renamed it to "operation nodes" since they are not actually SQL AST, but kinda like "kysely query builder AST" or something 😄

[igalklebanov]

We could go towards more generic ASTish nodes and rename it to BinaryOperationNode and also have UnaryOperationNode for exists etc. unary operations. We'll need these anyway if we implement the full expression builder at some point. What do you think?

We already have these "semantic" parent nodes like WhereNode and OnNode so we wouldn't lose any "transformability".

Sounds good!

I originally called the node tree AST but renamed it to "operation nodes" since they are not actually SQL AST, but kinda like "kysely query builder AST" or something 😄

😆 KyselyAST™️ has a nice ring to it!