We're starting to write more dialect-specific code in translator.rs; e.g. #858

What's the best design for this?

• Currently we have a mix of methods on Dialect structs https://github.com/prql/prql/blob/a1919f5504974878a1f8c763cb43cb5cac4f7d7f/prql-compiler/src/ast/dialect.rs#L90-L97 and match expressions in translate_* functions https://github.com/prql/prql/blob/a1919f5504974878a1f8c763cb43cb5cac4f7d7f/prql-compiler/src/sql/translator.rs#L801-L802. If we continue with this, what should go in each?
• We're sometimes using bare functions like https://github.com/prql/prql/blob/a1919f5504974878a1f8c763cb43cb5cac4f7d7f/prql-compiler/src/sql/translator.rs#L699 and sometimes using From impls https://github.com/prql/prql/blob/a1919f5504974878a1f8c763cb43cb5cac4f7d7f/prql-compiler/src/sql/translator.rs#L901
  • rust-analyzer has upcoming improved support for From, so it'll be less of an issue to track down the specific impl, which I've found inconvenient historically
• Should we do something like ast_fold.rs, where each Dialect "inherits" from a generic dialect, using this "Fold" pattern to generate a sql AST from constituent parts? This kinda emulates inheritance in Rust.
  • Note that these functions have different input and output types, so it might be a slightly different design
• I added a question https://github.com/prql/prql/blob/a1919f5504974878a1f8c763cb43cb5cac4f7d7f/prql-compiler/src/ast/dialect.rs#L29-L31 on whether we had the right design for Dialects. We're swapping between them at the moment; e.g. https://github.com/prql/prql/blob/a1919f5504974878a1f8c763cb43cb5cac4f7d7f/prql-compiler/src/sql/translator.rs#L798

Anything else?