three isuues about duckdb

[l1t1]

when using duckdb-polyglot,

It automatically removes line breaks.

It cannot recognize differences in the same operator across different dialects. For example, / in PostgreSQL represents integer division, while / in DuckDB represents regular division.

D SELECT * FROM polyglot_query('SELECT 1/2', 'postgresql');
┌─────────┐
│ (1 / 2) │
│ double  │
├─────────┤
│   0.5   │
└─────────┘

It cannot distinguish between variables and literal constants. Literal constants like 1 and 2 are obviously not NULL, yet it performs unnecessary checks.

SELECT polyglot_transpile('SELECT decode(1,2,3,4)', 'oracle');
┌───────────────────────────────────────────────────────────────────────┐
│        polyglot_transpile('SELECT decode(1,2,3,4)', 'oracle')         │
│                                varchar                                │
├───────────────────────────────────────────────────────────────────────┤
│ SELECT CASE WHEN 1 = 2 OR (1 IS NULL AND 2 IS NULL) THEN 3 ELSE 4 END │
└───────────────────────────────────────────────────────────────────────┘

[tobilg]

Thanks for reporting! Both fixes will be in the upcoming 0.1.6 release

[tobilg]

This should be fixed in the 0.1.6 release that was just published. Please check and close the issue if your problem is solved. Thanks!

[l1t1]

I tried the duckdb-polyglot again, it seems that extension is still the old version.
could you tell me how to test the 0.1.6 release?

[tobilg]

The DuckDB extension is not yet released. But you can test this with the Rust crate or the TypeScript SDK until it is.

[tobilg]

The DuckDB extension was release today with version 0.1.13. Please check again.

[l1t1]

memory D SELECT * FROM polyglot_query('SELECT 1/2', 'postgresql');
┌─────────┐
│ (1 / 2) │
│ double  │
├─────────┤
│     0.5 │
└─────────┘
memory D SELECT polyglot_transpile('SELECT decode(1,2,3,4)', 'oracle');
┌────────────────────────────────────────────────────────┐
│ polyglot_transpile('SELECT decode(1,2,3,4)', 'oracle') │
│                        varchar                         │
├────────────────────────────────────────────────────────┤
│ SELECT CASE WHEN 1 = 2 THEN 3 ELSE 4 END               │
└────────────────────────────────────────────────────────┘
memory D SELECT polyglot_transpile('SELECT decode(NULL,2,3,4)', 'oracle');
┌───────────────────────────────────────────────────────────┐
│ polyglot_transpile('SELECT decode(NULL,2,3,4)', 'oracle') │
│                          varchar                          │
├───────────────────────────────────────────────────────────┤
│ SELECT CASE WHEN NULL = 2 THEN 3 ELSE 4 END               │
└───────────────────────────────────────────────────────────┘
memory D SELECT polyglot_transpile('SELECT decode(NULL,NULL,3,4)', 'oracle');
┌──────────────────────────────────────────────────────────────┐
│ polyglot_transpile('SELECT decode(NULL,NULL,3,4)', 'oracle') │
│                           varchar                            │
├──────────────────────────────────────────────────────────────┤
│ SELECT CASE WHEN NULL IS NULL THEN 3 ELSE 4 END              │
└──────────────────────────────────────────────────────────────┘

thank you.
decode funtion of oracle is ok,
integer division of postgres should return 0 in my example.

[tobilg]

@l1t1 you're raising a valid observation but it's not a bug in the transpiler.

Here's the breakdown:

The claim: SELECT 1/2 transpiled from PostgreSQL should return 0, but DuckDB returns 0.5.

What's actually happening:

• In PostgreSQL, / between two integer literals performs integer division → 1/2 = 0
• In DuckDB (at least the version the commenter is using), / between two integer literals performs float division → 1/2 = 0.5
• The transpiler correctly outputs SELECT 1 / 2 — the SQL syntax is identical in both dialects
• The semantic difference is in how each database's runtime evaluates / on integer operands

Why this isn't fixable at the transpiler level:

• This is a type-dependent runtime behavior, not a syntax difference
• The transpiler would need full type inference to know that 1 and 2 are integers and that PostgreSQL's / means integer division in this context
• Python sqlglot has the exact same behavior — it passes 1 / 2 through unchanged
• For column references like SELECT a / b FROM t, the transpiler can't know the types of a and b without schema information

So: valid observation about a real semantic difference between databases, but not something a syntax-level transpiler can address. It would require type inference + schema awareness to emit CAST(1 / 2 AS INTEGER) or 1 // 2 for DuckDB targets.