Backport #100607 to 25.8.16: Re-add {database} macro support in clickhouse-client prompt

[il9ue]

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Re-add support for the {database} macro in the clickhouse-client and clickhouse-local prompt (prompt_by_server_display_name). The database name now updates dynamically after USE statements and correctly reflects the --database CLI flag and server-side default_database configuration. (ClickHouse#100607 by @il9ue)

Backport of ClickHouse/ClickHouse#100607 to releases/25.8.16. Closes upstream issue ClickHouse/ClickHouse#49118.

Summary of changes

• ClientBase::getPrompt() now dynamically substitutes {database} from default_database, which is updated on USE and by the --database flag.
• New ClientBase::syncDefaultDatabase() fires SELECT currentDatabase() after the connection handshake so the prompt reflects the server-side default_database when --database is not passed. Failure is logged and degrades gracefully.
• Call in Client::connect() is guarded by is_interactive && default_database.empty() && prompt.find("{database}") — no extra round-trip in batch mode, when --database was passed, or when the macro is absent from the prompt.
• {database} added to the macro documentation in programs/client/clickhouse-client.xml.
• Expect tests for both clickhouse-client (04056_client_prompt_database.expect) and clickhouse-local (04057_local_prompt_database.expect).

Note on local build
Local build was blocked by a pre-existing clang-21 -Wmissing-noreturn error in base/base/JSON.cpp (from the POCO_IMPLEMENT_EXCEPTION macro), unrelated to this backport. Relying on CI for verification. If 04057_local_prompt_database.expect fails, the first thing to check is --enable-progress-table-toggle=0 — that flag came from the upstream PR and I was unable to verify it exists in releases/25.8.16's clickhouse-local.

Note on upstream status
Upstream ClickHouse/ClickHouse#100607 is currently open (approved LGTM by @ilejn, awaiting CI trigger from a maintainer). Happy to wait for upstream merge before landing this in Stable if that's Altinity's preferred policy.

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)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [85ca839]

[il9ue]

On PR #1688's regression failure (settings/default values/allow_local_data_lakes):

The entry exists in the >=25.8_altinity snapshot (line 177, since clickhouse-regression on 0b98a129d, April 13). The framework's logic in settings/tests/default_values.py:75-83 should select that file for an Altinity non-Antalya 25.8 build, which my build is. Yet the test throws SnapshotNotFoundError as if the snapshot file or entry isn't
being found.

Some quick checks I ran:

• File exists, entry is at line 177, value matches what binary reports
• Binary version is 25.8.16.10002.altinitytest (note the altinitytest
  suffix)
• check_if_altinity_build / check_if_not_antalya_build both should
  return True for this version string

My best guess is the altinitytest suffix is hitting a code path that the regression framework hasn't been tested against (maybe check_clickhouse_version(">=25.8") parses the version differently than the altinity helpers do). But I haven't been able to confirm without running locally.

Is there a known issue here, or someone who knows the version-detection logic best?
Glad to investigate further or apply a fix once we know which side of the boundary it's on (framework vs. my build config).

[ianton-ru]

LGTM