BigQuery→DuckDB: NUMERIC(p, s) precision and scale dropped by transpile

[nikchha]

Explicit precision and scale on BigQuery NUMERIC(p, s) are dropped when transpiling to DuckDB, which changes query results without any error.

Version: @polyglot-sql/sdk 0.12.1, DuckDB 1.5.5

Repro

transpile('SELECT CAST(1.005 AS NUMERIC(10, 2)) AS a', Dialect.BigQuery, Dialect.DuckDB).sql[0];

Actual

SELECT CAST(1.005 AS DECIMAL) AS a

In DuckDB, bare DECIMAL is DECIMAL(18, 3), so this returns 1.005. BigQuery returns 1.01.

Parse followed by generate keeps the type (generate(parse(sql, Dialect.BigQuery).ast, Dialect.DuckDB) gives DECIMAL(10, 2)), so it seems to be lost in the transpile transforms.

Expected

SELECT CAST(1.005 AS DECIMAL(10, 2)) AS a

This matches sqlglot's output.

Related: bare NUMERIC

A bare BigQuery NUMERIC is NUMERIC(38, 9), but it is emitted as bare DECIMAL (or as DECIMAL(18, 3) when it is the argument of ROUND). Both mean DECIMAL(18, 3) in DuckDB, so ROUND(CAST(0.1249 AS NUMERIC), 2) returns 0.13 in DuckDB versus 0.12 in BigQuery. sqlglot behaves the same way here, so this may be intended, but emitting DECIMAL(38, 9) would preserve BigQuery semantics.

[tobilg]

Thanks for reporting, this will be fixed in the 0.13.0 release that will be done today. Please check and close if this fixed your issue.