iffyio commented on code in PR #2101:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/2101#discussion_r2560975570
##########
src/dialect/mod.rs:
##########
@@ -601,13 +601,122 @@ pub trait Dialect: Debug + Any {
false
}
- /// Return true if the dialect supports specifying multiple options
+ /// Returns true if the dialect supports specifying multiple options
/// in a `CREATE TABLE` statement for the structure of the new table. For
example:
/// `CREATE TABLE t (a INT, b INT) AS SELECT 1 AS b, 2 AS a`
fn supports_create_table_multi_schema_info_sources(&self) -> bool {
false
}
+ /// Returns `true` if the dialect supports qualified column names
+ /// as part of a MERGE's INSERT's column list. Example:
+ ///
+ /// ```sql
+ /// MERGE INTO FOO
+ /// USING FOO_IMP
+ /// ON (FOO.ID = FOO_IMP.ID)
+ /// WHEN NOT MATCHED THEN
+ /// -- no qualifier
+ /// INSERT (ID, NAME)
+ /// VALUES (FOO_IMP.ID, UPPER(FOO_IMP.NAME))
+ /// ```
+ /// vs.
+ /// ```sql
+ /// MERGE INTO FOO
+ /// USING FOO_IMP
+ /// ON (FOO.ID = FOO_IMP.ID)
+ /// WHEN NOT MATCHED THEN
+ /// -- here: qualified
+ /// INSERT (FOO.ID, FOO.NAME)
+ /// VALUES (FOO_IMP.ID, UPPER(FOO_IMP.NAME))
+ /// ```
+ /// or
+ /// ```sql
+ /// MERGE INTO FOO X
+ /// USING FOO_IMP
+ /// ON (X.ID = FOO_IMP.ID)
+ /// WHEN NOT MATCHED THEN
+ /// -- here: qualified using the alias
+ /// INSERT (X.ID, X.NAME)
+ /// VALUES (FOO_IMP.ID, UPPER(FOO_IMP.NAME))
+ /// ```
+ ///
+ /// Note: in the latter case, the qualifier must match the target table
+ /// name or its alias if one is present. The parser will enforce this.
+ ///
+ /// The default implementation always returns `false` not allowing the
+ /// qualifiers.
+ fn supports_merge_insert_qualified_columns(&self) -> bool {
+ false
+ }
+
+ /// Returns `true` if the dialect supports specify an INSERT predicate in
Review Comment:
I meant for us to not introduce settings for the feature. Take for example
the [copy
statement](https://github.com/xitep/datafusion-sqlparser-rs/blob/b0c0ae2e0e0a3ea4b40ea9515fce5202a76f13f9/src/parser/mod.rs#L9907)
isn't supported by some dialects but the parser accepts it regardless of the
configured dialect - this is OK behavior for the parser (it would be unwieldy
for the parser to attempt to model all differences across all dialects
otherwise). The dialects have their use reserved for the scenarios where its
required to distinguish behavior or features that are more pronounced
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
