alexander-beedie opened a new pull request, #2174: URL: https://github.com/apache/datafusion-sqlparser-rs/pull/2174
## Preamble There have been a number of requests https://github.com/apache/datafusion-sqlparser-rs/issues/1430 to make `Dialect` derivation easier but there have remained some practical issues around implementation. This PR represents an attempt at a streamlined option that covers 95% of what people want to do with essentially _zero_ impact on existing code, while remaining largely future-proofed. It is complementary to, and compatible with, longer-term efforts to move away from internal calls to `dialect_of!` (such as https://github.com/apache/datafusion-sqlparser-rs/pull/2171). ## Implementation A new `derive_dialect!` proc macro has been created and added to `sqlparser_derive`, and is feature-gated behind a new `"derive-dialect"` feature. If you don't enable the feature, nothing changes - the _sole_ impact on the rest of the codebase would be that each defined `Dialect` is marked with `#[derive(Debug, Default)]` instead of just `#[derive(Debug)]` - that's it. The code in `sqlparser_derive` was split into "visit.rs" (existing visitor macros) and "dialect.rs" (the new dialect derivation macros). In use, the macro discovers all the boolean traits of the base `Dialect` at compile time (plus the `identifier_quote_style` char definition) and allows them to be selectively overridden. Because it does this, new boolean traits added to future releases are automatically included. All non-overridden traits defer to the base. ## In use In addition to the desired boolean overrides, you can set `preserve_type_id=true` to have the derived dialect be recognised as equivalent to the base for internal `dialect_of!` checks. This makes it easy to support use-cases like that of @samuelcolvin in https://github.com/apache/datafusion-sqlparser-rs/issues/1430, which was _"I want to use 'from first' syntax with otherwise postgres syntax"_ (example below). If/when internal use of `dialect_of!` is phased out, this macro would remain a streamlined way of deriving new `Dialect` classes (so if "preserve_type_id" loses meaning, the utility of the macro remains, and we can phase out that param or leave as-is). ## Example ```rust use sqlparser::derive_dialect; use sqlparser::dialect::{Dialect, PostgreSqlDialect}; derive_dialect!(EnhancedPostgreSqlDialect, PostgreSqlDialect, overrides = { supports_from_first_select = true }, preserve_type_id = true, ); ``` The derived dialect has the requested traits... ```rust let dialect = EnhancedPostgreSqlDialect::new(); assert!(dialect.supports_from_first_select()); ``` ...but still identifies internally as a valid `PostgreSqlDialect`: ``` let d: &dyn Dialect = &dialect; assert!(d.is::<PostgreSqlDialect>()); ``` ## References There are a few others (closed/open), but these cover most of the key points: * https://github.com/apache/datafusion-sqlparser-rs/pull/1448/ * https://github.com/apache/datafusion-sqlparser-rs/issues/1430 * https://github.com/apache/datafusion-sqlparser-rs/pull/2171 -- 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]
