sap hana dialect added

[tglunde]

1. Changes

• HANA Dialect Implementation: Added HanaDialect to support SAP HANA Cloud SQL, including tokenizer and generator configurations (Oracle-style identifiers, string quoting, uppercase keywords).
• Function Transpilation to Trino: Implemented transform_expr() and transform_function() to map ~40 HANA-specific functions to generic AST nodes so they correctly generate Trino SQL. This includes date arithmetic (ADD_DAYS, MONTHS_BETWEEN), string operations (LCASE, LOCATE), null handling (NVL, IFNULL), and datetime constants (CURRENT_UTCTIMESTAMP).
• Date Format Token Conversion: Added convert_hana_to_java_format() to translate HANA's Oracle-style date format tokens (e.g., YYYY, HH24, MI, PM) into Java SimpleDateFormat tokens (e.g., yyyy, HH, mm, a), specifically for DATE_FORMAT and DATE_PARSE compatibility in Trino.
• Custom Data Type Mappings: Extended the DataType::Custom logic in generator.rs to correctly map proprietary HANA types (SMALLDECIMAL, SECONDDATE, ALPHANUM, CLOB, etc.) to standard equivalents (DECIMAL, TIMESTAMP, VARCHAR) while preserving scale, precision, and length arguments.
• Test Coverage: Added extensive JSON fixtures (identity.json, transpilation.json, types.json, functions.json, ddl.json, dml.json) to verify parsing logic and Trino translations.

2. Impact

• Cross-Dialect Capability: Directly unlocks the ability to transpile native SAP HANA queries into Trino SQL, a primary requirement for migrating or federating queries into a data lakehouse.
• Safe Codebase Extension: Safely leverages existing cross-dialect normalization rules. Standard functions already covered by TrinoDialect simply pass through unmodified, keeping the HanaDialect footprint small and safe.
• No Breaking Changes: The core parser modifications and generator type rules isolate HANA specifics. Existing dialect identity and transpilation tests remain stable.

3. What to Watch Out For on Review

• LOCATE Argument Swap: HANA uses LOCATE(substr, str) while Trino uses STRPOS(str, substr). Verify the parameter extraction and swapping logic inside transform_function("LOCATE") correctly handles the semantic difference.
• HANA FLOAT to DOUBLE Cast: Under the hood, HANA's FLOAT implies 64-bit precision. Verify the logic translating DataType::Float { real_spelling: false } into DataType::Double meets interoperability expectations without losing precision.
• Date Format Mapping Edge Cases: Review the TOKENS array in convert_hana_to_java_format(). Ensure all critical HANA date tokens map accurately and that the loop appropriately skips and preserves unknown or literal characters safely.
• Data Type Parameters: In generator.rs, ensure that when proprietary types like ALPHANUM(n) or SMALLDECIMAL(p, s) are mapped to VARCHAR(n) and DECIMAL(p, s), the parser arguments string (_args_str) is being securely appended after the generic type name keyword.

[tobilg]

Thanks for opening the PR. Please remove to .opencode directory and the AGENTS.md, as I do not want to include them in this project.

[tglunde]

Hi, what about the openspec definitions. Should they stay or go as well?

[tobilg]

Thanks for opening the PR. Please remove to .opencode directory and the AGENTS.md, as I do not want to include them in this project.

Yes, please remove them as well, thanks

[tobilg]

Thanks for the SAP HANA dialect contribution. I reviewed the PR locally and the core direction looks useful, especially for HANA-to-Trino migration workflows. I would ask for a few changes before merging.

What I checked locally:

cargo fmt --check
cargo check -p polyglot-sql --no-default-features --features "generate,transpile,dialect-hana,dialect-trino"
cargo test -p polyglot-sql --test custom_dialect_tests --features all-dialects -- --nocapture
cargo check -p polyglot-sql-wasm --no-default-features --features dialect-hana
cargo test -p polyglot-sql-ffi test_dialect_list_and_count -- --nocapture

The HANA custom fixtures passed: 132 identity cases and 80 transpilation cases. The feature-gated Rust/WASM/FFI checks above also passed. git diff --check currently reports a whitespace issue in openspec/specs/hana-dialect/spec.md.

Main points to address:

• The Trino date/time format conversion looks incorrect. The PR converts HANA masks such as YYYY-MM-DD to Java-style yyyy-MM-dd, but Trino/Presto DATE_FORMAT and DATE_PARSE use MySQL/percent-style tokens such as %Y-%m-%d. This also differs from the local SQLGlot Presto/Trino behavior.
• HANA identity behavior currently normalizes native HANA functions such as ADD_DAYS and NVL into generic/Trino-like forms. That is useful for source transpilation, but it means HANA self-transpilation does not preserve HANA-native SQL for those constructs. We should clarify whether this PR is adding a full HANA read/write dialect or primarily a HANA source dialect for Trino.
• The HANA-specific custom type mappings are implemented in the global generator path for every non-HANA target. It would be safer to keep those rewrites scoped to HANA source transformation so unrelated dialects or user-defined custom types are not affected.
• The PR duplicates format-token scanning logic. Current main already has an internal format-token helper, so after rebasing this should use that shared helper instead.
• The PR includes unrelated project files and formatting-only changes (mise.toml, OpenSpec archive/spec files, TypeScript test formatting churn). Please remove anything not required for the dialect addition.
• Dialect counts/docs should be normalized. Some docs say 33 dialects while other generated/runtime lists count generic/internal dialects differently.

Overall: this is a valuable addition, but I would not merge it as-is. Once the date-format semantics, HANA identity scope, generator scoping, and PR hygiene are cleaned up, this should be much easier to review and likely merge.