feat(executor): implement DPIPE [CLAUDE]

[jbylund]

DPIPE is absent from the executor's ENV, so || raises rather than answering:

>>> execute("SELECT a || b FROM t", tables=t).rows
ExecuteError: Step 'Join: t (...)' failed: name 'DPIPE' is not defined

Approach

No DPIPE function is added. The generator routes || to functions that already exist, choosing by the operand's annotated type:

def _dpipe_sql(self: generator.Generator, e: exp.DPipe) -> str:
    if e.this.is_type(exp.DataType.Type.ARRAY) or e.expression.is_type(exp.DataType.Type.ARRAY):
        return self.func("ARRAYCONCAT", e.this, e.expression)

    return self.func("SAFECONCAT" if e.args.get("safe") else "CONCAT", e.this, e.expression)

The source dialect is not available at codegen — the executor generates from the optimized tree — so safe (not STRICT_STRING_CONCAT) is the only source-dialect signal that survives parsing. It decides whether a non-string operand coerces or raises. Types come from the optimizer, which execute() already runs; execute() also infers them from tables=.

ARRAYCONCAT

exp.ArrayConcat was already generating ARRAYCONCAT(...) via _rename into an ENV with no such key, so ARRAY_CONCAT and ARRAY_CAT raised NameError as well. The one new function fixes those too.

Behaviour, and one open choice

arrayconcat wraps a non-list operand so that an element appends to an array. That single line is the one place this diverges by dialect, so both versions are shown. Checked against PostgreSQL 18.4, SQLite 3.51 and DuckDB 1.5.5:

	as written	without the wrap	postgres	sqlite	duckdb
'a' || 'b'	ab	ab	ab	ab	ab
'a' || 1	a1	a1	a1	a1	a1
'a' || NULL	NULL	NULL	NULL	NULL	NULL
ARRAY[1,2] || ARRAY[3]	[1,2,3]	[1,2,3]	{1,2,3}	n/a	[1,2,3]
ARRAY[1,2] || 3	[1,2,3]	error	{1,2,3}	n/a	error
3 || ARRAY[1,2]	[3,1,2]	error	{3,1,2}	n/a	error
1 || 2	12	12	error	12	12

There is no dialect-neutral option: the engines disagree, and the executor has one ENV shared by all of them with safe as the only dialect knob the parser records. Dropping the wrap does not remove a dialect-specific behaviour, it selects DuckDB's instead of Postgres'. So the question is which divergence to take.

Written as it is, || mostly follows Postgres.

The stricter alternative is available rather than impossible: the same type information would support raising wherever any of the three engines would — both operands known-numeric gives Postgres' rejection of 1 || 2, an array beside a bare element gives DuckDB's. It would be best-effort, since operands are UNKNOWN where nothing annotates them, and it has to test for known-numeric rather than for not-text, because a string literal is not always annotated either. I have not taken it because it is more conservative than the surrounding executor, not because it cannot be done: 1 || 2 lands as '12' here by routing to the existing SAFECONCAT, which is right for the CONCAT function — Postgres coerces there too, concat(1,2) is 12 — though Postgres' || operator does require one operand to already be text.

MySQL is unaffected throughout — || is logical OR there, so sqlglot parses it to Or, not DPipe. Under presto/trino — the only dialects setting STRICT_STRING_CONCAT — 'a' || 1 raises instead, matching the engine.

Full suite: 1321 tests, OK.

[georgesittas]

Why are we overloading || to concatenate lists here? What dialect's semantics are you implementing?

[jbylund]

I was looking at a combination of postgres/sqlite and duckdb. I've just pushed a new update which is mostly (but not entirely) consistent with postgres. The different dbs vary here - I'd prefer a behavior closer to postgres, but I think there are a few different choices you could make here (but it does appear you have to trade something away in any choice).

[georgesittas]

Should this be safe_concat only if "safe" is truthy? Otherwise I think we'd need to match the semantics of the source dialect and crash if there's a non-string input.

[jbylund]

Yes, I think test_dpipe_source_dialect_coercion should now cover that?