No cross-database surface: attach/detach unwrapped, and ManagedDatabase discards attachments

[rohan-hotdata]

Re-scoped 1 Sep 2026 after measuring it. This was filed as "attach/detach are unwrapped in
HDLC". That framing was wrong: the platform refuses the attach for managed databases, so
wrapping alone would not have delivered what the downstream workload wanted. What is left is
two smaller, real asks. Original framing kept below the line.

What was measured

Against the live workspace, 31 Aug – 1 Sep:

Attempt	Result
attach managed database A into managed database B	refused — Connection '<id>' is scoped to another database and cannot be attached here
load a result_id from A's query into a table in A	OK, 1 row landed
load the same result_id into B	refused — Result '<id>' not found
attach a Postgres connection into a managed database	accepted
SELECT * FROM catalog.public.drivers through that alias	859 rows, from inside the managed database's scope

ResultsApi.get_result also takes a required x_database_id, which is the same boundary
expressed in a signature.

So: managed databases cannot see each other; registered data sources attach as designed.
The read side of a multi-catalog database already works end to end — query_catalogs()
discovers the alias and sql_tool_description already tells the model to read table_catalog
when there is more than one.

What HDLC should actually do

1. Wrap attach_database_catalog / detach_database_catalog on the framework client and
   expose them, gated like other provisioning tools (see Provisioning boundary: agent-driven database, table, and index lifecycle #61). Today they are raw-SDK only, so
   any consumer wanting a multi-catalog database drops out of the library to build one.
2. Stop discarding attachment state. managed_database_from_detail keeps only id, name
   and default_connection_id. DatabaseDetailResponse also carries default_catalog,
   default_schema and attachments — all three dropped, so a caller cannot ask what is
   attached to a database without going around the library.

Both are ordinary wrapping work. Neither depends on a platform change.

What is not being asked for here

"Let a managed database be attached as a catalog" is a product question, not an HDLC one. It
may well be worth raising — it is a real gap for the agent-creates-databases story — but it
belongs upstream and nothing downstream is waiting on it. The consumer workload has moved to
hosting its shared catalog as a Postgres connection, which is measured working.

Also note fork_database is on no framework version at all — raw SDK only — if anyone
picks that up while in here.

---

Original framing (filed 31 Aug, before measurement)

hotdata-langchain has no cross-database surface at all. Every tool set is scoped to
exactly one ManagedDatabase, resolved once at build time, and execute_sql sends a single
X-Database-Id. The machinery exists on the raw SDK, unwrapped, and every managed database
exposes its catalog handle as ManagedDatabase.default_connection_id — so attaching one
managed database into another looked reachable. Measuring it showed it is not.

[rohan-hotdata]

Re-scoped the body above after measuring this. Short version: the attach is refused for managed databases (Connection '<id>' is scoped to another database), so this was never just a wrapping gap. But a Postgres connection attaches cleanly and reads across the boundary — 859 rows from catalog.public.drivers inside a managed database's scope. So the two asks that remain are real and small: wrap attach/detach, and stop discarding attachments/default_catalog/default_schema from the detail response. The "let a managed database be attachable" question is a product ask, not an HDLC one, and nothing downstream is blocked on it.

[rohan-hotdata]

Both wrapping asks here are now filed upstream, where the fix belongs: hotdata-dev/sdk-python-framework#81.

attach_database_catalog/detach_database_catalog are on no HotdataClient version, and managed_database_from_detail lives in hotdata_framework, so this repo cannot stop the discarding in place.

#97 delivers what this issue needs from the library side — hl.attach_catalog, hl.detach_catalog and hl.database_attachments, going through DatabasesApi(client.api) — but it satisfies the second ask without fixing its cause, which is why I have not closed this. Leaving it open against the upstream ticket.