Extend Expr

[Huliiiiii]

While I working on #463, I discovered that some expressions could not be represented using the existing Expr variants This includes both space-separated and comma-separated expression lists, such as those found in
https://www.postgresql.org/docs/current/functions-json.html#SQLJSON-QUERY-FUNCTIONS

JSON_EXISTS (
context_item, path_expression
[ PASSING { value AS varname } [, ...]]
[{ TRUE | FALSE | UNKNOWN | ERROR } ON ERROR ]) → boolean

My idea is to add a new variant to support this.

Expr::List(Separator, Vec<Expr>)

The separator can be &str or a enum.

What do you think? @Expurple @tyt2y3

[Expurple]

We can go with an enum similar to BinOper, with a Custom(&'static str) variant. &'static str a little less flexible than Cow<'static, str> used for identifiers, but building custom separators at runtime should be very uncommon.

Edit: Function::Custom holds a DynIden, we can go with that too

[tyt2y3]

I guess it comes down to how to the chain of Expr it typically will be? if it's only a few we can model that with nesting (linked by Expr::Binary), but if it can be long then a Vec is better.

[Expurple]

My updated opinion, originally posted here:

For flexibility, we already have cust* methods and Cust/Custom variants. I adore them. When something isn't supported natively, they usually provide a working solution. I'm not sure if we need a different, semi-structured "arbitrary node" workaround in addition to that.

I know that you need #926. But if we look closer at it, an "expression list" isn't itself a valid expression that can be freely composed with other expressions. Which means that ExprList should be a separate type, rather than a new variant of Expr. I think, we should add that type, then add a backend function to render that into an SQL string, and then you can safely format that rendered string into a bigger raw string that comprises your JSON_EXISTS function call.