DSL for JDBC expression rewrites

[findepi]

Introduce DSL for building function pushdown rules in JDBC.

As we are building up a registry of allowed function pushdowns, the
declaration verbosity matters. This commit adds support for defining
rewrite rules tersely.

As a usage example, a previously hand-written RewriteLike rule is now
replaced with a mere one-liner:

.map("$like_pattern(value: varchar, pattern: varchar): boolean").to("value LIKE pattern")

Relates to #18

[findepi]

Currently depends on #11086

cc @wendigo @hashhar @losipiuk @martint @assaf2 @ebyhr @grantatspothero

[findepi]

cc @slhmy

[grantatspothero]

Can we get away with writing the AST manually in java instead of defining an antlr grammar/using a visitor to create the AST?

In my opinion, this doesn't seem too bad to manually write. But maybe others feel differently 🤷‍♀️

new CallPattern(
                        "$like_pattern",
                        List.of(
                                new ExpressionCapture("value", type("varchar")),
                                new ExpressionCapture("pattern", type("varchar"))),
                        Optional.of(type("boolean"))

[grantatspothero]

Maybe adding a test case for a more complex example would show the benefits of the DSL?

[findepi]

The DSL syntax here is similar to SQL, so hopefully feels familiar, with notable differences:

• call parameters have explicit types, call result has optional explicit type (this is central for function pattern matching)
• $ sign is allowed in identifiers, so that we don't need quotes

In my view, your example already proves the value.
The had to use CallPattern, List, ExpressionCapture, type, Optional for the same effect, without adding any actual value for readability (quite contrary, IMO).

[findepi]

(rebased)

[findepi]

Rebased on current top of #11086.
@wendigo 's #11308 helped me to identify a bug in the generic rewrite.

[findepi]

rebased and fixed codestyle issues.

[findepi]

When reviewing, you can start from here:

[hashhar]

Everything except GenericRewrite#rewrite looks good to me % comments.

[hashhar]

I won't pretend I'm very familiar with ANTLR - I'll review this in detail later.

[findepi]

i guess @martint @kasiafi and maybe @electrum are.

[hashhar]

Makes sense to me + Antlr usage matches existing code in other places.

[hashhar]

i.e. Maybe someone with Antlr API usage knowledge can take a look - maybe @martint / @kasiafi .

[martint]

Note that these are not SQL identifiers (no delimited vs non-delimited), so they should be treated as already-canonicalized. Also, that implies that the character set is potentially anything that can go inside a delimited SQL identifier (i.e., any UTF-8 character). This is going to be hard to do without introducing some kind of escaping for whitespace or other characters.

Concretely, if a SQL query does something like:

SELECT "123 some function"(a, b, c) FROM t

(i.e., it calls a function named 123 some function)

That name needs to be representable in this grammar. The following pattern would obviously not work due to 1) whitespace 2) leading numbers in the function name:

123 some function(a : varchar, b : varchar, c : varchar) : bigint

[findepi]

Note that these are not SQL identifiers (no delimited vs non-delimited)

yes, they aren't

. so they should be treated as already-canonicalized.

in a sense of lower/upper-case?
yes, it should be case-sensitive

Also, that implies that the character set is potentially anything that can go inside a delimited SQL identifier (i.e., any UTF-8 character). This is going to be hard to do without introducing some kind of escaping for whitespace or other characters.

For such a case we will introduce quotes to allow a name be anything.
We don't have such need yet, but once we have, we'll do it.

[findepi]

note that this is convenience syntax to simplify most of the cases. It doesn't need to support all the cases. For example, it doesn't support varargs today. It can be made to support varargs, and we may or may not choose to add that, depending on demand. "99%" cases are function names that are ordinary words, with fixed number of arguments, potentially with overloads for different types.