From b48b0cb6e20a9d32000e9ad86914dff66796f5ae Mon Sep 17 00:00:00 2001
From: Eddie A Tejeda <669988+eddietejeda@users.noreply.github.com>
Date: Mon, 24 Aug 2026 17:43:43 -0700
Subject: [PATCH] docs: adopt instant database terminology in hand-written
 prose

Rename "managed database" / "managed catalog" to "instant database" /
"instant catalog" in hand-written prose (integration test docstring and
comments, changelog note). Documentation only: public API symbols keep
their existing "managed" naming for compatibility, and quoted server
error messages are left verbatim. Generated modules and docs echo the
OpenAPI spec prose and will pick up the new wording on the next
regeneration from the updated spec.
---
 CHANGELOG.md                                       | 5 +++++
 tests/integration/test_managed_tables_lifecycle.py | 8 ++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2bcba5a..69bf3a5 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -9,6 +9,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- docs: adopt "instant database" / "instant catalog" terminology in hand-written
+  prose. Documentation only — all public API symbols (`ManagedTableResponse`,
+  `load_managed_table`, the `managed` source type, etc.) are unchanged for
+  compatibility. Generated docstrings pick up the new wording on the next client
+  regeneration from the updated OpenAPI spec.
 - feat(query): add dialect parameter to query request
 
 ## [0.10.0] - 2026-08-18
diff --git a/tests/integration/test_managed_tables_lifecycle.py b/tests/integration/test_managed_tables_lifecycle.py
index 7215e68..239cf9b 100644
--- a/tests/integration/test_managed_tables_lifecycle.py
+++ b/tests/integration/test_managed_tables_lifecycle.py
@@ -1,18 +1,18 @@
 """Scenario: managed_tables_lifecycle.
 
 The heaviest scenario — it ties databases, uploads, and managed tables together
-against a fresh scratch database (whose default catalog is a managed catalog):
+against a fresh scratch database (whose default catalog is an instant catalog):
 
   1. declare a schema and a table on the database's default catalog connection,
   2. upload a small parquet file,
   3. load it into the table (load_managed_table) and verify the load response,
   4. delete the managed table.
 
-Notes on managed-catalog semantics (all confirmed against prod). A managed
+Notes on instant-catalog semantics (all confirmed against prod). An instant
 catalog rejects the maintenance ops that apply to external catalogs, so this
 scenario deliberately omits them:
 
-  * No `refresh` step — rejected with 400 on a managed catalog ("use the loads
+  * No `refresh` step — rejected with 400 on an instant catalog ("use the loads
     endpoint to update its data"); `load_managed_table` is itself the load.
   * No `purge_table_cache` step — rejected with 400 ("purge not supported for
     managed catalogs").
@@ -55,7 +55,7 @@ def test_managed_tables_lifecycle(
     uploads_api: UploadsApi,
     scratch_database: str,
 ) -> None:
-    # The database's auto-provisioned default catalog is a managed catalog,
+    # The database's auto-provisioned default catalog is an instant catalog,
     # addressed through its default_connection_id.
     connection_id = databases_api.get_database(scratch_database).default_connection_id
     schema_name = "sdkci_mt"