Antalya 26.8: Native CREATE TABLE / DROP TABLE for DataLakeCatalog; optionally prune on DROP

[zvonand]

Dropped from this backport: the AI dropped these surfaces rather than pulling in a missing prerequisite. Reviewers: confirm each is genuinely optional.

• UnityV2 catalog support (UnityV2Catalog.{h,cpp}, its CREATE TABLE branches, integration test) — depends on the upstream UnityV2 catalog feature not on antalya-26.8
• DeltaLake catalog registration and DeltaLakeMetadataDeltaKernel createTable/createInitial (incl. UnityCatalog::createTable) — depends on the upstream DeltaLake catalog CREATE TABLE feature not on antalya-26.8

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Supports CREATE TABLE, CREATE TABLE … AS source, and DROP TABLE for DataLakeCatalog; DROP TABLE can request catalog-side data purge via the new data_lake_delete_data_on_drop setting (ClickHouse#98670 by @zvonand).

Cherry-picked from ClickHouse#98670.

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [f8d6c83]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2443 (head f8d6c83)

Verdict: CI is red, but none of the failures are caused by this PR. Every failing
check is pre-existing / infra / flaky at the antalya-26.8 branch level. I confirmed this
by comparing against a small, unrelated sibling PR on the same base — #2541 (a one-line
nullcheck) shows the exact same failure set: Grype (keeper + server-alpine), the
amd_asan_ubsan integration shard 3/8, Parser memory check, and 60 Regression modules.

Evidence base: the authoritative praktika report for this commit
(result_pr.json, run 38143533818).
In that run the PR's own functional surface is green (details below).

---

Per-failure classification

1. Parser memory check — ERROR → infra, not PR-related
Decisive line from the report: step "Resolve master binary" → No master clickhouse-examples artifact was found (Failures: 1/2).
The job compares this PR's binary parser memory against a master baseline binary; that
baseline artifact wasn't published, so the job errored before running any comparison. Same
error on #2541. → Re-run once a master clickhouse-examples build exists; nothing to fix in this PR.

2. Grype Scan (clickhouse-keeper, clickhouse-server -alpine) — fail → pre-existing, not PR-related
Container image vulnerability scans: 4 high/critical (keeper), 1 high/critical (server-alpine).
These are CVEs in the base image OS packages/libraries. This PR changes only src/ C++ and
integration-test .py/.xml files — no Dockerfiles, no dependency or submodule bumps — so it
cannot introduce or remove these. Identical on #2541. → Base-image refresh / allowlist at branch level.

3. Integration tests (amd_asan_ubsan, db disk, old analyzer, 3/8) — fail → stale + pre-existing, not PR-related
In this commit's run the job is SKIPPED (Antalya CI excludes the ubsan tag), so it did not
even execute here — the fail (1/715) entry is a stale check-run. The same shard fails on #2541
(where it did run, ~1h29m), so it's a pre-existing flaky/broken test on the branch. Crucially, the
integration tests that did run on #2443 — Integration tests (arm_binary, distributed plan, 1..4/4),
which include the Iceberg/Glue DataLake tests this PR actually touches — all passed with 0 failures.

4. Regression (aarch64) — 60 modules fail → flaky / infra, not PR-related
Altinity TestFlows regression suite run against the merge commit. Failing modules span
aggregate_functions, alter_*, lightweight_delete, atomic_insert, engines, selects,
oauth, s3/azure — none of which touch DataLakeCatalog CREATE/DROP TABLE. The cas_*
modules show the classic infra pattern 35 retries (7 ok, 2 failed, 26 retried) = environment/setup
retries, not test-logic failures. The same 60 regression modules are red on #2541. → Systemic; triage at branch level.

5. "Unit tests (asan_ubsan / msan / tsan)" and the aggregate "PR" gate
The sanitizer unit-test checks are SKIPPED in this run (Antalya excludes ubsan/tsan/msan);
their fail entries in gh pr checks are stale check-runs. The top-level PR check is just the
aggregate gate going red because of the checks above.

---

Health check (what this PR's own CI proves)

All builds succeeded (amd/arm debug, binary, release). Functional coverage is green:

• Stateless tests: 0 failures — amd_debug parallel 13,251 ✓ / sequential 951 ✓, distributed-plan+s3 parallel 12,941 ✓ / sequential 894 ✓, arm_binary parallel 13,366 ✓ / sequential 965 ✓.
• Integration tests (arm_binary, distributed plan, 4 shards): 0 failures (~7,679 tests), including this PR's Iceberg/Glue DataLake tests.
• Stress tests (amd/arm debug, arm release): 0 failures. AST fuzzer / BuzzHouse completed (timeout = normal end, no crash). Compatibility + install-packages: pass. SQLLogic / SQLStorm within thresholds.

Recommendation: no code changes are warranted for any of the failing checks — they are
environmental/pre-existing and equally red on the unrelated sibling PR #2541. The Parser memory check
can be re-run once master artifacts are available; the Grype and regression/amd_asan_ubsan
integration failures need branch-level attention, not a change here.

_{— @blau-ai · evidence: praktika run 38143533818, comparison PR #2541. I can't build/run ClickHouse in this job, so this is a static + CI-report triage.}