Module connection 

Database client for mz-deploy.

This module provides the main Client struct for interacting with Materialize. The client handles connection management and delegates specialized operations to domain-specific sub-clients.

Sub-Client Architecture

Operations are grouped into domain sub-clients accessed via accessor methods on Client. Each sub-client borrows the Client and provides a focused API:

Sub-client	Accessor	Responsibility
DeploymentsClient	.deployments()	Deployment lifecycle (stage, promote, abort)
DeploymentsClientMut	.deployments_mut()	Mutable deployment ops (SUBSCRIBE cursors)
IntrospectionClient	.introspection()	Read-only catalog metadata queries
ValidationClient	.validation()	Pre-deployment environment checks
TypeInfoClient	.types()	Column/type introspection for type checking
ProvisioningClient	.provisioning()	Idempotent DDL for databases, schemas, clusters

TLS Policy

Per-profile sslmode with libpq semantics (disable, prefer, require, verify-ca, verify-full). When unset, loopback hosts default to prefer and everything else defaults to require. See the design at docs/superpowers/specs/2026-04-22-profile-tls-design.md for the behavior table and migration notes.

Structs

Client

Database client for interacting with Materialize.

DeploymentsClient

Domain sub-client for deployment lifecycle operations.

DeploymentsClientMut

Domain sub-client for deployment operations that require mutable client access.

DevOverlaysClient

Domain sub-client for developer overlay manifest operations.

IntrospectionClient

Domain sub-client for metadata and object introspection operations.

ProvisioningClient

Domain sub-client for provisioning databases, schemas, and clusters.

TypeInfoClient

Domain sub-client for column/type introspection used by type checking and tests.

ValidationClient

Domain sub-client for project and privilege validation operations.

Enums

CaSource 🔒

Where the CA bundle comes from for verifying the server cert, or the absence thereof for non-verifying modes.

Connector 🔒

Runtime-ready connector variant handed to tokio_postgres::Config::connect.

ConnectorSpec 🔒

Pure-data representation of the TLS setup for a connection, derived from a profile’s effective SslMode and sslrootcert.

HostCheck 🔒

How verify-full should match the cert’s SAN entries.

Constants

APPLICATION_NAME 🔒

DEFAULT_CA_PATHS 🔒

Platform CA bundle candidates, walked in order by build_connector when sslmode resolves to verify-ca / verify-full and the profile does not set sslrootcert. Kept in sync with libpq-like installations on our supported platforms.

Functions

build_connector 🔒

Convert a ConnectorSpec into a runtime Connector by wiring up the OpenSSL context. All filesystem I/O for CAs happens here.

build_options_string 🔒

Build the inner value of the libpq options connection parameter from a profile’s options map.

classify_connect_error 🔒

Classify a tokio_postgres::Error surfaced from Config::connect(...) into the most specific ConnectionError variant.

default_sslmode 🔒

The default SslMode applied when a profile does not set sslmode.

escape_options_value 🔒

Escape a value for embedding inside the libpq options connection parameter.

is_loopback_host 🔒

Returns true if host names the loopback interface.

matches_tls_refused_message 🔒

Pure string check for the substrings tokio_postgres produces when the server refuses the TLS startup request (responds 'N' to the SSL byte).

message_indicates_tls_refused 🔒

Heuristic: does the error look like “server said no to our TLS request”?

plan_connector 🔒

Plan the TLS setup for a connection from the resolved (mode, CA) inputs.

resolve_ca_source 🔒

ssl_error_in_chain 🔒

Walk the source chain of a tokio_postgres::Error and return the string form of the first openssl::error::ErrorStack found.

tokio_ssl_mode 🔒