Oracle: Support for MERGE predicates

[xitep]

Oracle supports small extensions to the standard MERGE syntax (that I'd need to support.) In particular:

• ... WHEN MATCHED ... UPDATE ... ***[WHERE <expr>] [DELETE WHERE <expr>]***
• ... WHEN NOT MATCHED ... INSERT ... ***[WHERE <expr>]***

Here's the documentation for reference.

Quoted column names

Additionally, Oracle also allows quoted names in MERGE INTO a.b ... INSERT (a.b.col1, a.b.col2) ... (or event ... INSERT (b.col1, b.col2) ... with the same meaning as ... INSERT (col1, col2) as long as a.b denotes the target table of the merge.

For the sake of compatibility, this draft PR makes a trade-off: the parser validates that "a.b." corresponds to the target table, and strips away the prefix in order to keep MergeInsertExpr::columns a Vec<Ident>. While preserving semantics, the implication is that such a parsed statements doesn't render back in the exact same form, though.

Not doing the validation and stripping, we'd probably need to end up with a Vec<QualifiedName>. I would be glad to hear your opinion how to move forward. Personally, I'd be fine with the Vec<QualifiedName> allowing me to re-produce the statement as originally written.

Note

1. I have moved the MERGE parsing code to a dedicated sub-module (and make Parser::merge_parse_clauses private.)
2. I have introduced a Merge struct akin to Insert, Update, ... this makes it easier to pass the merge-relevat data around in a type-safe way
3. I'd greatly appreciate any feedback to be able to steer this into a desired direction.

Missing

• Location information in error messages
• Expose insert columns as Vec<ObjectName>
• Entirely remove the "insert column" semantic validation

[iffyio]

@xitep Re this and #2103 PRs, The parser currently doesn't support oracle as a dialect, so that it would be a bit confusing going forward having code specific to the dialect but being unable to guarantee its consistency/behavior. I'm thinking we could instead start by introducing oracle as a supported dialect here?

[xitep]

• yeah, i think starting an OracleDialect would definitely be the proper way forward. (it's just a much broader change than i think i can manage right now.)
• wrt: Preserve optional AS keyword in aliases #2103: i think that is not (very) oracle specific. (truth is, the "AS" keyword will break the queries on oracle DBs; an OracleDialect would surely need to do something about it.) but primarily i see the change as a step towards "...recover(ing) the original SQL text..." (README.md.)

[xitep]

so that it would be a bit confusing going forward having code specific to the dialect

i would have a draft of an OracleDialect here ... would you like to have it rather as a separate PR (or include in into this one?) there's surely quite some work left on full oracle support (eg. string literals with a quote_delimiter) but it would be a start at least.