[DK09876]

Problem

Three code paths emit PostgreSQL-specific SQL (or rely on PG-only out-bind behavior) that breaks on the Oracle 23ai backend:

1. Recall (ORA-03048) — retrieve_temporal_combined expands a batch of seed ids for multi-hop temporal-link spreading with FROM unnest($2::uuid[]) AS src(from_unit_id). Oracle has no unnest, so recall fails whenever the matched memories have temporal/causal links — i.e. most real queries.

2. Mental-model history (ORA-00907) — update_mental_model trims the history array in SQL using jsonb_agg(... ORDER BY ...) over jsonb_array_elements(...) WITH ORDINALITY. This errors on Oracle, and because creating a mental model triggers a refresh that updates content, mental-model creation fails entirely on Oracle.

3. RETURNING CLOBs (ORA-22835) — the Oracle RETURNING handler binds non-numeric/non-timestamp output columns as DB_TYPE_VARCHAR, which caps at 4000 bytes. Any CLOB-backed column returned via RETURNING raises ORA-22835: buffer too small for CLOB to CHAR conversion once it exceeds 4000 bytes. Surfaces as mental-model refresh failing when the synthesized content is large.

Fix

1. Recall — guard the multi-hop spreading loop on the connection's backend_type. On backends without unnest we skip only the spread; temporal entry points and the semantic/keyword/graph retrievers are unaffected.

2. Mental-model history — on Oracle, compute the trimmed history in Python (the current array is already fetched) and bind it as a single JSON value. The PostgreSQL SQL path is unchanged.

3. RETURNING CLOBs — bind known CLOB columns (the JSON-as-CLOB set plus large-text columns content/text/context/structured_content/text_signals/search_vector) as DB_TYPE_CLOB, and read the LOB handle back to a string in _read_returning_values (the async pool yields AsyncLOB, whose read() is awaited). Non-CLOB columns are unchanged.

All three are instances of the dialect-asymmetry trap called out in CLAUDE.md.

Test plan

• Oracle 23ai e2e smoke + HTTP integration: mental-model create / CRUD, full-lifecycle, retain (incl. tags), and document/memory CRUD pass.
• Full Oracle integration suite: zero ORA-03048 and ORA-22835 occurrences; recall returns results on linked memories at all budgets.
• Direct check: a 4277-byte CLOB now round-trips through UPDATE ... RETURNING (previously ORA-22835); RAW(16) ids still convert correctly.
• PostgreSQL mental-model history unit tests (including max-entries trimming) still pass — the PG path is byte-identical.

🤖 Generated with Claude Code

[nicoloboschi]

Merged main and extended the recall fix for the new temporal selection that just landed in #1983.

Why this was needed: #1983 rewrote the temporal entry-point selection to gate candidates by embedding similarity within the window, and that new query expanded fact_types with FROM unnest($3::text[]) AS ft CROSS JOIN LATERAL (...). unnest has no Oracle translation — so after #1983 merged, Oracle recall would again hit ORA-03048, this time in the entry-point query (the supports_unnest guard in this PR only covers the multi-hop spread).

Fix: rebuilt the entry-point query as a UNION ALL of one similarity-ranked, window-filtered arm per fact_type with the fact_type inlined as a literal — the same shape retrieve_semantic_bm25_combined already uses and which Oracle runs. <=>→VECTOR_DISTANCE and LIMIT→FETCH FIRST are handled by the existing translator; only unnest was the blocker and it's gone.

Verified:

• PG behavior unchanged — temporal selection tests pass; recall_perf temporal arm ~0.002s on the 680k dense bank.
• Oracle output checked through the real _rewrite_pg_to_oracle: no unnest, valid VECTOR_DISTANCE + FETCH FIRST, binds intact.

The Oracle e2e suite in CI here should now exercise the temporal recall path end-to-end.