Streamlined derivation of new Dialect objects

[alexander-beedie]

derive_dialect!(new, base, preserve_type_id = …, overrides = { … })

Preamble

There have been a number of requests #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 the majority of what people want to do with no impact on existing code, while also 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 #2171).

Implementation

Introduces a derive_dialect! proc macro in sqlparser_derive, gated behind the 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)], which should be zero-cost for unit/empty structs.

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; new boolean traits added in future releases would be automatically discovered/included, with non-overridden traits deferring to the base.

The code in sqlparser_derive was split into "visit.rs" (existing visitor macros) and "dialect.rs" (the new dialect derivation macro/helpers) for clarity.

In use

As well as the desired boolean overrides, you can set preserve_type_id=true to have the derived dialect be recognised as equivalent to the base, allowing the derived dialect to pass equivalence-checks for the remaining internal dialect_of! calls. This makes it easy to support use-cases like that of @samuelcolvin in #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 nice streamlined way of deriving new Dialect objects (so if "preserve_type_id" loses meaning, the utility of the macro remains, and we could either phase out that param or leave as-is).

Example:

use sqlparser::derive_dialect;
use sqlparser::dialect::{Dialect, PostgreSqlDialect};

derive_dialect!(EnhancedPostgreSqlDialect, PostgreSqlDialect,
    overrides = {
        supports_order_by_all = true,
        supports_from_first_select = true,
        supports_triple_quoted_string = true,
    },
    preserve_type_id = true,
);

The derived dialect has the requested trait values...

let dialect = EnhancedPostgreSqlDialect::new();

assert!(dialect.supports_order_by_all());          // → true
assert!(dialect.supports_from_first_select());     // → true
assert!(dialect.supports_triple_quoted_string());  // → true

...but still identifies internally as a valid PostgreSqlDialect:

let d: &dyn Dialect = &dialect;
assert!(d.is::<PostgreSqlDialect>());  // → true

References

There are a few others (closed/open), but these cover the key points:

• Add a note discouraging new use of dialect_of macro #1448
• stop the use of dialect_of and referring to specific dialects in parser #1430
• Refactor: replace some dialect_of! checks with Dialect trait methods #2171

[iffyio]

LGTM! Thanks @alexander-beedie!

[alexander-beedie]

LGTM! Thanks @alexander-beedie!

Great, thanks :)