Skip to content

Huawei Cloud DWS connector

GaussDB(DWS) is a distributed warehouse derived from PostgreSQL. It uses the standard PostgreSQL wire driver in Dosi; it is not the gaussdb connector, whose private SHA256 authentication requires a different driver.

The important DWS-specific property is pg_database.datcompatibility. Every database is ORA, TD, or MYSQL, and that value affects SQL semantics. Dosi therefore resolves it from the connected database before compiling SQL and keeps it in the compiled query metadata through execution.

Connection profile

datasources:
  warehouse-td:
    type: dws
    host: ${DWS_HOST}
    port: 8000
    database: ${DWS_DATABASE_TD}
    username: ${DWS_USERNAME}
    password: ${DWS_PASSWORD}
    schema: public
    sslmode: verify-full
    sslrootcert: /etc/ssl/certs/dws-ca.pem
    compat_mode: TD
Key Type Required Default Meaning
host string yes, unless uri is set — DWS endpoint.
port int no 8000 DWS service port for a discrete-field profile.
database string yes — The database whose compatibility mode is probed.
username / password string normally — PostgreSQL-wire credentials; environment expansion is supported.
schema string no public Session search_path.
sslmode / sslrootcert string no prefer / none Same TLS ladder as PostgreSQL. Verification modes require a CA bundle.
compat_mode ORA, TD, or MYSQL no probed Optional assertion. A mismatch with the database fails before compilation.
uri string alternative — A complete postgres://...:8000/... URI, including its port. compat_mode remains a separate key.

Do not copy one profile and change its database at runtime. Use one named profile per database; the successful mode cache belongs to that profile, so a TD database can never populate an ORA database's compilation context.

Compatibility modes

Dosi runs this exact probe through the selected connection:

SELECT datcompatibility
FROM pg_database
WHERE datname = current_database();

Unknown or unreadable values fail closed. SQL compiled as dws_ora, dws_td, or dws_mysql is accepted only by an executor that resolves the same mode. All three currently use the shared PostgreSQL-compatible renderer; the mode is still explicit compiler input so verified mode-specific lowerings can be added without changing the API or risking cross-database reuse.

For compilation without a connection, supply the mode explicitly:

dosi --model model.yaml query --metrics revenue --dialect dws --dws-mode td

Execution should use a named profile so Dosi can probe the live database:

dosi --model model.yaml query --metrics revenue --execute --connection warehouse-td

Validation

The declarative corpus shares its models, seeds, queries, and expected rows with the other warehouses. DWS has three independent execution targets: dws_ora, dws_td, and dws_mysql. Each target has its own epoch, SQL gold, receipt, and cloud job, so success in one mode never claims support for another.

For DWS 8.2.1 compatibility, corpus setup does not use CREATE SCHEMA IF NOT EXISTS (that syntax was added in DWS 9.1). Corpus fixture models qualify physical tables as main.<table>, so each mode database must already contain a writable main schema. The cloud workflow pins DWS_SCHEMA=main, and the testkit rejects other values instead of seeding one schema and querying another. This is a corpus constraint only; ordinary DWS connection profiles can use any existing schema.

See also