ts-prorm-orm 1.1.0 → 1.2.1

package/dist/dialects/redshift/index.d.ts

@@ -0,0 +1,933 @@
+/**
+ * Amazon Redshift dialect implementation for the TypeScript ORM
+ *
+ * Redshift speaks the PostgreSQL wire protocol (it is a fork of Postgres 8.0.2),
+ * so this dialect reuses the `pg` driver exactly like the Postgres dialect and
+ * mirrors much of its query-building behavior. However, Redshift diverges from
+ * Postgres in ways that matter a lot in practice — two gotchas in particular:
+ *
+ * 1. FOREIGN KEY / UNIQUE / PRIMARY KEY constraints are accepted syntactically
+ *    (and stored in the catalog for the query planner / documentation
+ *    purposes) but are **NEVER enforced** at write time. `INSERT`/`UPDATE`
+ *    statements that violate a declared FK or UNIQUE constraint will succeed
+ *    silently. Do not rely on Redshift to guarantee referential integrity or
+ *    uniqueness — enforce that in application code. See the inline comments
+ *    on `getColumnDefinitionSql`, `buildConstraintSql`, `addForeignKey`,
+ *    `createConstraint` below for where this shows up.
+ *
+ * 2. There are no traditional B-tree secondary indexes. Instead, performance
+ *    is governed by table-level `DISTSTYLE`/`DISTKEY` (how rows are
+ *    distributed across compute node slices) and `SORTKEY` (how rows are
+ *    physically ordered on disk, either `COMPOUND` or `INTERLEAVED`). These
+ *    are specified via `RedshiftTableOptions` on `createTable` and emitted
+ *    directly in the `CREATE TABLE` DDL. Methods that would create a
+ *    traditional index (`addIndex`, `createIndex`, `createPartialIndex`, ...)
+ *    throw a clear error pointing callers at DISTKEY/SORTKEY instead.
+ *
+ * Other notable differences from the Postgres dialect:
+ * - Default port is 5439 (not 5432).
+ * - No native JSON/JSONB type before Redshift's semi-structured `SUPER` type;
+ *   `getDataTypeSql` maps both `JSON` and `JSONB` DataTypes to `SUPER`.
+ * - Auto-increment columns use `IDENTITY(seed, step)` rather than
+ *   `SERIAL`/`BIGSERIAL`.
+ * - `MERGE` is only available in Redshift starting ~2023 and `ON CONFLICT`
+ *   has never been supported, so `buildUpsertQuery` does NOT generate
+ *   `INSERT ... ON CONFLICT DO UPDATE` (that would simply fail against a real
+ *   cluster prior to MERGE support, and is not portable). Instead it
+ *   generates AWS's own documented staging-table + `DELETE` + `INSERT`
+ *   pattern. See the comment on `buildUpsertQuery` for the full rationale.
+ * - Bulk loads are normally done via `COPY FROM S3` rather than row-by-row
+ *   `INSERT`. `copyFromS3()` is added as an extra (non-`Dialect`-interface)
+ *   method for that; ordinary `bulkInsert`/`buildInsertQuery` still work via
+ *   plain multi-row `INSERT` for compatibility with the rest of the ORM.
+ * - No triggers, no sequences (`CREATE SEQUENCE`/`nextval`), no row-level
+ *   security policies, and no foreign-data-wrapper support (Redshift uses
+ *   Redshift Spectrum's `CREATE EXTERNAL SCHEMA` for federated/external data
+ *   instead). All of these throw a clear, explanatory `Error`.
+ * - Redshift *does* support views, materialized views (with optional
+ *   `AUTO REFRESH`), and a limited form of stored procedures
+ *   (`CREATE OR REPLACE PROCEDURE ... LANGUAGE plpgsql`), so those are
+ *   implemented much like Postgres.
+ */
+import type { Pool, PoolClient } from 'pg';
+import { Dialect, DialectOptions, ColumnDefinition, TableOptions, DropTableOptions, TableDescription, IndexOptions, IndexDefinition, InsertOptions, UpdateOptions as DUpdateOptions, DeleteOptions, SelectOptions, UpsertQueryOptions, CreateExtensionOptions, DropExtensionOptions, ExtensionInfo, FdwForeignServerOptions, FdwAlterForeignServerOptions, FdwUserMappingOptions, FdwForeignTableOptions, FdwImportForeignSchemaOptions, ConstraintDefinition, DropConstraintOptions, DropIndexOptions, ViewOptions, DropViewOptions, DropSchemaOptions, MaterializedViewOptions, RefreshOptions, DropMaterializedViewOptions } from '../dialect';
+import { Transaction, TransactionOptions, QueryResult, QueryOptions, DataType, WhereOptions, Order, CreatePartitionOptions, AttachPartitionOptions, DetachPartitionOptions, StoredProcedureOptions, DropStoredProcedureOptions, ExecuteStoredProcedureOptions, TriggerOptions, DropTriggerOptions, SequenceOptions, DropSequenceOptions, PolicyOptions, DropPolicyOptions, StreamOptions } from '../../types';
+import { Readable } from 'stream';
+/**
+ * Redshift-specific extensions to `TableOptions` for the `DISTSTYLE` /
+ * `DISTKEY` / `SORTKEY` table-level performance clauses that replace
+ * traditional B-tree indexes in Redshift.
+ */
+export interface RedshiftTableOptions {
+    /**
+     * Distribution style. `KEY` requires `distKey` to also be set. Defaults to
+     * Redshift's own default (`AUTO`) when omitted.
+     */
+    diststyle?: 'EVEN' | 'KEY' | 'ALL' | 'AUTO';
+    /** Column used to distribute rows across slices when diststyle is 'KEY'. */
+    distKey?: string;
+    /** Column(s) used to physically order rows on disk. */
+    sortKey?: string | string[];
+    /** Sort key algorithm. Defaults to COMPOUND (Redshift's own default) when a sortKey is given. */
+    sortkeyType?: 'COMPOUND' | 'INTERLEAVED';
+}
+/**
+ * Redshift-specific extensions to `MaterializedViewOptions`.
+ *
+ * Redshift materialized views support several clauses beyond the plain
+ * boolean `AUTO REFRESH YES` this dialect originally emitted:
+ * - `BACKUP NO` opts the view's data out of automated cluster snapshots
+ *   (commonly used for views cheap to rebuild, to save snapshot storage/time).
+ * - `DISTKEY`/`SORTKEY`/`DISTSTYLE` on the materialized view itself, exactly
+ *   like `RedshiftTableOptions` on `createTable`.
+ */
+export interface RedshiftMaterializedViewOptions {
+    /** Whether AUTO REFRESH is enabled at creation time. */
+    autoRefresh?: boolean;
+    /** Set to `false` to emit `BACKUP NO`, excluding the view's data from automated cluster snapshots. Defaults to Redshift's own default (BACKUP YES) when omitted. */
+    backup?: boolean;
+    /** Distribution style for the materialized view's underlying result table. */
+    diststyle?: 'EVEN' | 'KEY' | 'ALL' | 'AUTO';
+    /** Column used to distribute rows when diststyle is 'KEY'. */
+    distKey?: string;
+    /** Column(s) used to physically order rows on disk. */
+    sortKey?: string | string[];
+    /** Sort key algorithm. Defaults to COMPOUND when a sortKey is given. */
+    sortkeyType?: 'COMPOUND' | 'INTERLEAVED';
+}
+/**
+ * Redshift-specific extension to `ColumnDefinition` adding column-level
+ * compression `ENCODE` types (e.g. `AZ64`, `ZSTD`, `LZO`, `BYTEDICT`,
+ * `RUNLENGTH`, `DELTA`, `RAW`, ...). This is a first-class, perf-critical
+ * Redshift DDL feature and a natural sibling to `RedshiftTableOptions`'s
+ * `distKey`/`sortKey`. Emitted in `getColumnDefinitionSql` immediately after
+ * the column's data type, matching Redshift's own
+ * `column_name data_type ENCODE encoding-type` syntax.
+ */
+export interface RedshiftColumnDefinition {
+    /**
+     * Compression encoding for this column. Accepts any of Redshift's
+     * documented encoding types (`AZ64`, `ZSTD`, `LZO`, `BYTEDICT`, `DELTA`,
+     * `DELTA32K`, `MOSTLY8`, `MOSTLY16`, `MOSTLY32`, `RUNLENGTH`, `TEXT255`,
+     * `TEXT32K`, `RAW`, ...); passed through verbatim so newer encoding types
+     * Redshift adds in the future work without a dialect update.
+     */
+    encode?: string;
+}
+/**
+ * Options accepted by `copyFromS3` for Redshift's bulk-load `COPY` command.
+ */
+export interface CopyFromS3Options {
+    /** IAM role ARN to use for the COPY (mutually exclusive with credentials). */
+    iamRole?: string;
+    /** Static AWS credentials to use for the COPY (mutually exclusive with iamRole). */
+    credentials?: {
+        accessKeyId: string;
+        secretAccessKey: string;
+        sessionToken?: string;
+    };
+    /** Source data format. Defaults to CSV. */
+    format?: 'CSV' | 'JSON' | 'PARQUET' | 'AVRO' | 'ORC';
+    /** Field delimiter for CSV/delimited data. Defaults to ','. */
+    delimiter?: string;
+    /** Path to a JSON 'jsonpaths' file, or 'auto' for JSON format. */
+    jsonOption?: string;
+    /** Number of header rows to skip (CSV). */
+    ignoreHeader?: number;
+    /** Region the S3 bucket lives in, if not the cluster's default region. */
+    region?: string;
+    /** Compression of the source files. */
+    compression?: 'GZIP' | 'BZIP2' | 'ZSTD';
+    /** Continue loading when a threshold of rows have errors. */
+    maxError?: number;
+    /** Additional raw COPY options appended verbatim (escape hatch). */
+    extra?: string;
+}
+/**
+ * Options accepted by `unloadToS3` for Redshift's bulk-export `UNLOAD`
+ * command — the write-side counterpart to `copyFromS3`.
+ */
+export interface UnloadOptions {
+    /** IAM role ARN to use for the UNLOAD (mutually exclusive with credentials). */
+    iamRole?: string;
+    /** Static AWS credentials to use for the UNLOAD (mutually exclusive with iamRole). */
+    credentials?: {
+        accessKeyId: string;
+        secretAccessKey: string;
+        sessionToken?: string;
+    };
+    /** Output file format. Defaults to plain delimited text (Redshift's UNLOAD default) when omitted. */
+    format?: 'PARQUET' | 'CSV' | 'JSON';
+    /** Field delimiter for delimited text output. Ignored for PARQUET/JSON. */
+    delimiter?: string;
+    /** Split output across slices in parallel (Redshift's default). Set to false to force a single output file (PARALLEL OFF). */
+    parallel?: boolean;
+    /** Compress the output files. */
+    compression?: 'GZIP' | 'BZIP2' | 'ZSTD';
+    /** Maximum size of each output file/part. */
+    maxFileSize?: string;
+    /** Region the destination S3 bucket lives in, if not the cluster's default region. */
+    region?: string;
+    /** Write a manifest file listing the unloaded data files. */
+    manifest?: boolean;
+    /** Overwrite existing files at the destination prefix. */
+    allowOverwrite?: boolean;
+    /** Add a header row with column names (CSV/text output only). */
+    header?: boolean;
+    /** Additional raw UNLOAD options appended verbatim (escape hatch). */
+    extra?: string;
+}
+/**
+ * Redshift-specific extensions to `UpsertQueryOptions`.
+ */
+export interface RedshiftUpsertOptions {
+    /**
+     * Emit a native `MERGE INTO ... USING ... WHEN MATCHED / WHEN NOT MATCHED`
+     * statement instead of the staging-table + DELETE + INSERT workaround.
+     *
+     * Redshift only added `MERGE` support in 2023 (and it requires a reasonably
+     * modern maintenance track), so this is opt-in rather than the default —
+     * set it to `true` only when you know the target cluster supports `MERGE`.
+     * When `true`, the whole upsert becomes a single atomic statement, so the
+     * transaction-wrapping performed by `upsert()`/`bulkUpsert()` is not
+     * strictly required for atomicity (though it's still applied for a
+     * consistent calling convention).
+     */
+    useMerge?: boolean;
+    /**
+     * Columns to SET on `WHEN MATCHED THEN UPDATE`, when `useMerge` is used.
+     * Defaults to all non-conflict columns (mirrors `updateOnDuplicate`).
+     */
+    updateColumns?: string[];
+}
+/**
+ * Redshift-specific extensions to `TransactionOptions`.
+ *
+ * Redshift only supports two isolation levels via `BEGIN`/`SET TRANSACTION`:
+ * READ COMMITTED (the default) and SERIALIZABLE. The ANSI READ
+ * UNCOMMITTED/REPEATABLE READ levels have no equivalent and are rejected.
+ */
+export interface RedshiftTransactionOptions extends TransactionOptions {
+    /** Mark the transaction READ ONLY (true) or explicitly READ WRITE (false). */
+    readOnly?: boolean;
+}
+/**
+ * Options accepted by `vacuum()`.
+ */
+export interface RedshiftVacuumOptions {
+    /**
+     * Which vacuum operation to run. Defaults to a full `VACUUM` (resorts and
+     * reclaims space). `SORT ONLY` re-sorts rows without reclaiming space,
+     * `DELETE ONLY` reclaims space from deleted rows without re-sorting, and
+     * `REINDEX` additionally rebuilds interleaved sort key indexes before
+     * doing a full vacuum.
+     */
+    mode?: 'FULL' | 'SORT ONLY' | 'DELETE ONLY' | 'REINDEX';
+    /** Vacuum to at least this percent sorted before stopping (1-100). */
+    toPercent?: number;
+    /** Boost the priority of the vacuum operation. */
+    boost?: boolean;
+}
+/**
+ * Options accepted by `analyze()`.
+ */
+export interface RedshiftAnalyzeOptions {
+    /** Only analyze these columns (mutually exclusive with `predicateColumns`). */
+    columns?: string[];
+    /** Restrict ANALYZE to columns that have been used as predicates. */
+    predicateColumns?: boolean;
+}
+/**
+ * Options accepted by `createDatashare()`.
+ *
+ * NOTE: unlike most Redshift `CREATE ...` statements, `CREATE DATASHARE`
+ * does NOT support an `IF NOT EXISTS` clause (verified against the AWS
+ * documentation) - creating a datashare that already exists is a plain
+ * error. There is therefore no `ifNotExists` option here.
+ */
+export interface CreateDatashareOptions {
+    /**
+     * Emits `SET PUBLICACCESSIBLE TRUE|FALSE`, controlling whether the
+     * datashare can be shared to publicly-accessible consumer clusters.
+     * Redshift's own default (when omitted) is `FALSE`.
+     */
+    publiclyAccessible?: boolean;
+}
+/**
+ * Consumer/target of `GRANT USAGE ON DATASHARE ... TO ...`.
+ *
+ * Redshift's `GRANT USAGE ON DATASHARE` grants either to a namespace GUID
+ * within the same account (`TO NAMESPACE 'guid'`) or to a whole other AWS
+ * account (`TO ACCOUNT 'accountnumber' [VIA DATA CATALOG]`) - never to an
+ * individual database user/role. `viaDataCatalog` is only meaningful (and
+ * only emitted) alongside `account`.
+ */
+export type DatashareGrantTarget = {
+    account: string;
+    viaDataCatalog?: boolean;
+} | {
+    namespace: string;
+};
+/**
+ * Options accepted by `createDatabaseFromDatashare()`.
+ */
+export interface CreateDatabaseFromDatashareOptions {
+    /**
+     * Producer AWS account ID owning the datashare's namespace. Required for
+     * cross-account data sharing; omit it for same-account sharing (only
+     * `NAMESPACE` is then required, per AWS docs).
+     */
+    account?: string;
+    /**
+     * Emits `WITH PERMISSIONS`, requiring consumer-side grantees to be given
+     * object-level permissions individually rather than automatically getting
+     * access to every object in the database via a single `USAGE` grant.
+     */
+    withPermissions?: boolean;
+}
+/**
+ * Options accepted by `createExternalSchemaFederated()` for Redshift
+ * federated queries against a *live* Amazon RDS/Aurora PostgreSQL or MySQL
+ * database - as opposed to Redshift Spectrum's `CREATE EXTERNAL SCHEMA ...
+ * FROM DATA CATALOG/HIVE METASTORE`, which reads static files from S3
+ * through an external data catalog. Federated query connects directly to an
+ * OLTP database over the wire and is a distinct Redshift feature with its
+ * own `FROM POSTGRES` / `FROM MYSQL` syntax.
+ */
+export interface ExternalSchemaFederatedOptions {
+    /** Which federated engine the target database speaks. */
+    engine: 'POSTGRES' | 'MYSQL';
+    /** Name of the database on the remote PostgreSQL/MySQL server. */
+    database: string;
+    /**
+     * Remote schema name (PostgreSQL only - `SCHEMA` isn't supported for
+     * federated queries to MySQL, which has no separate schema namespace
+     * beyond the database itself). Defaults to `public` on the Postgres side
+     * when omitted.
+     */
+    schema?: string;
+    /** Hostname of the RDS/Aurora endpoint (the URI clause). */
+    uri: string;
+    /** Port to connect on. Defaults to 5432 (Postgres) / 3306 (MySQL) when omitted. */
+    port?: number;
+    /** IAM role ARN (or `'default'`) Redshift assumes to read the Secrets Manager secret. */
+    iamRole: string;
+    /** ARN of the AWS Secrets Manager secret holding the remote database credentials. */
+    secretArn: string;
+    /** Emits `IF NOT EXISTS` after `CREATE EXTERNAL SCHEMA`. */
+    ifNotExists?: boolean;
+}
+/**
+ * Amazon Redshift dialect class implementing the Dialect interface.
+ *
+ * See the module-level doc comment above for the two biggest Postgres ->
+ * Redshift surprises: unenforced FK/UNIQUE constraints, and DISTKEY/SORTKEY
+ * replacing B-tree indexes.
+ */
+export declare class RedshiftDialect implements Dialect {
+    readonly name = "redshift";
+    readonly library = "pg";
+    private pool;
+    private _isConnected;
+    private config;
+    private transactionDepth;
+    constructor(config: RedshiftDialectOptions);
+    connect(): Promise<void>;
+    disconnect(): Promise<void>;
+    getConnection(): Pool | null;
+    isConnected(): boolean;
+    /**
+     * Stream query results by paging through `sql` via repeated
+     * dialect-appropriate LIMIT/OFFSET queries (see
+     * `createPaginatedQueryStream()` in `src/dialects/query-stream-helper.ts`)
+     * instead of loading the whole result set into memory at once.
+     * @param sql - The SELECT statement to stream
+     * @param options - Streaming options (batch size, backpressure watermark, model mapping)
+     */
+    queryStream(sql: string, options?: StreamOptions): Readable;
+    query(sql: string, options?: QueryOptions): Promise<QueryResult>;
+    private executeWithRetry;
+    escape(value: unknown): string;
+    private escapeString;
+    private formatDate;
+    escapeId(identifier: unknown): string;
+    quoteIdentifier(identifier: string): string;
+    quoteTable(tableName: string, schema?: string): string;
+    getDatabaseVersion(): Promise<string>;
+    createSchema(schema: string): Promise<void>;
+    dropSchema(schema: string, options?: DropSchemaOptions): Promise<void>;
+    showAllSchemas(): Promise<string[]>;
+    listSchemas(): Promise<string[]>;
+    createDatabaseSQL(options: {
+        name: string;
+    }): string;
+    dropDatabaseSQL(name: string): string;
+    createSavepointSQL(name?: string): string;
+    releaseSavepointSQL(name: string): string;
+    rollbackToSavepointSQL(name: string): string;
+    createExtension(_extensionName: string, _options?: CreateExtensionOptions): Promise<void>;
+    dropExtension(_extensionName: string, _options?: DropExtensionOptions): Promise<void>;
+    getExtensions(): Promise<ExtensionInfo[]>;
+    hasExtension(_extensionName: string): Promise<boolean>;
+    /**
+     * Create a table.
+     *
+     * Emits Redshift's DISTSTYLE/DISTKEY/SORTKEY table-level clauses (the
+     * replacement for traditional B-tree indexes) when present on `options`.
+     *
+     * FOREIGN KEY / UNIQUE / PRIMARY KEY constraints given via `options.constraints`
+     * are still emitted as DDL — Redshift's parser accepts the syntax and stores
+     * it in the catalog for the query planner and for documentation/ERD tooling
+     * — but NONE of them are enforced at write time. Do not rely on this DDL for
+     * actual data integrity guarantees.
+     */
+    createTable(tableName: string, columns: Record<string, ColumnDefinition>, options?: TableOptions & RedshiftTableOptions): Promise<void>;
+    /**
+     * Build constraint SQL for table creation.
+     *
+     * NOTE: Redshift accepts PRIMARY KEY / UNIQUE / FOREIGN KEY DDL but never
+     * enforces any of it. CHECK constraints are not supported at all by
+     * Redshift and will throw.
+     */
+    private buildConstraintSql;
+    /**
+     * Generate column definition SQL.
+     *
+     * Auto-increment columns use Redshift's `IDENTITY(seed, step)` clause
+     * instead of Postgres's `SERIAL`/`BIGSERIAL` (Redshift has no SERIAL type
+     * and no sequence objects backing it).
+     *
+     * Also emits Redshift's column-level `ENCODE <type>` compression clause
+     * (e.g. `ENCODE AZ64`, `ENCODE ZSTD`, `ENCODE BYTEDICT`, ...) immediately
+     * after the data type when `definition.encode` (see `RedshiftColumnDefinition`)
+     * is set. This is a perf-critical, Redshift-specific storage option with no
+     * Postgres equivalent.
+     */
+    private getColumnDefinitionSql;
+    private getDefaultValue;
+    dropTable(tableName: string, options?: DropTableOptions): Promise<void>;
+    createPartitionedTable(): Promise<void>;
+    createPartition(_options: CreatePartitionOptions): Promise<void>;
+    attachPartition(_options: AttachPartitionOptions): Promise<void>;
+    detachPartition(_options: DetachPartitionOptions): Promise<void>;
+    dropPartition(_partitionName: string, _options?: {
+        ifExists?: boolean;
+        cascade?: boolean;
+    }): Promise<void>;
+    createView(viewName: string, query: string, options?: ViewOptions): Promise<void>;
+    dropView(viewName: string, options?: DropViewOptions): Promise<void>;
+    showViews(): Promise<string[]>;
+    createMaterializedView(options: MaterializedViewOptions & RedshiftMaterializedViewOptions): Promise<void>;
+    refreshMaterializedView(viewName: string, _options?: RefreshOptions): Promise<void>;
+    /**
+     * Toggle Redshift's `AUTO REFRESH` mode on an existing materialized view
+     * after creation, via `ALTER MATERIALIZED VIEW ... AUTO REFRESH YES|NO`.
+     * This is distinct from `refreshMaterializedView`, which performs a single
+     * manual blocking refresh; this method instead changes whether Redshift
+     * automatically re-refreshes the view in the background going forward.
+     */
+    setMaterializedViewAutoRefresh(viewName: string, autoRefresh: boolean): Promise<void>;
+    dropMaterializedView(viewName: string, options?: DropMaterializedViewOptions): Promise<void>;
+    hasMaterializedView(viewName: string): Promise<boolean>;
+    showMaterializedViews(): Promise<string[]>;
+    addColumn(tableName: string, columnName: string, definition: ColumnDefinition): Promise<void>;
+    removeColumn(tableName: string, columnName: string): Promise<void>;
+    /**
+     * Change a column's type. Note: Redshift's ALTER COLUMN TYPE support is far
+     * more limited than Postgres's — it generally only allows widening VARCHAR
+     * lengths and a handful of numeric-type widenings, not arbitrary type
+     * changes. The SQL is still emitted here; Redshift itself will reject
+     * unsupported conversions.
+     */
+    changeColumn(tableName: string, columnName: string, definition: ColumnDefinition): Promise<void>;
+    renameColumn(tableName: string, oldColumnName: string, newColumnName: string): Promise<void>;
+    /**
+     * Add a foreign key to a table.
+     *
+     * IMPORTANT: Redshift accepts this DDL and records it in the catalog, but
+     * NEVER enforces it. Inserts/updates that violate the relationship will
+     * succeed. See class doc comment.
+     */
+    addForeignKey(tableName: string, columnName: string, referencedTableName: string, referencedColumnName: string, options?: {
+        name?: string;
+    }): Promise<void>;
+    bulkInsert(tableName: string, records: Record<string, any>[], _options?: any): Promise<QueryResult>;
+    /**
+     * Bulk-load data into a table from Amazon S3 using Redshift's `COPY`
+     * command. This is NOT part of the `Dialect` interface (it's Redshift-
+     * specific) — it's an addition on top of the standard CRUD surface, which
+     * still works via plain `INSERT` through `bulkInsert`/`buildInsertQuery`.
+     *
+     * Authentication is via either an IAM role ARN (recommended) or static
+     * credentials — exactly one of `options.iamRole` / `options.credentials`
+     * must be supplied.
+     */
+    copyFromS3(tableName: string, s3Path: string, options?: CopyFromS3Options): Promise<QueryResult>;
+    /**
+     * Bulk-export the result of a query to Amazon S3 using Redshift's `UNLOAD`
+     * command — the write-side counterpart to `copyFromS3`. Like `copyFromS3`,
+     * this is NOT part of the `Dialect` interface (it's Redshift-specific).
+     *
+     * Authentication is via either an IAM role ARN (recommended) or static
+     * credentials — exactly one of `options.iamRole` / `options.credentials`
+     * must be supplied.
+     *
+     * Builds: `UNLOAD ('<query>') TO 's3://...' IAM_ROLE '...' [FORMAT AS
+     * PARQUET|CSV|JSON] [DELIMITER ...] [PARALLEL ON|OFF] [MANIFEST] ...`
+     */
+    unloadToS3(query: string, s3Path: string, options?: UnloadOptions): Promise<QueryResult>;
+    /**
+     * `CREATE DATASHARE datashare_name [SET PUBLICACCESSIBLE TRUE|FALSE]`
+     *
+     * Creates a new datashare in the current database, owned by the issuing
+     * user. Adding objects to it is a separate step - see
+     * `alterDatashareAddSchema`/`alterDatashareAddTable`.
+     */
+    createDatashare(name: string, options?: CreateDatashareOptions): Promise<QueryResult>;
+    /**
+     * `DROP DATASHARE datashare_name`
+     *
+     * Irreversible. Only a superuser or the datashare owner can run this.
+     */
+    dropDatashare(name: string): Promise<QueryResult>;
+    /**
+     * `ALTER DATASHARE datashare_name ADD SCHEMA schema`
+     *
+     * Adding a schema does NOT add the objects inside it - each table still
+     * needs to be added explicitly via `alterDatashareAddTable`.
+     */
+    alterDatashareAddSchema(datashareName: string, schemaName: string): Promise<QueryResult>;
+    /**
+     * `ALTER DATASHARE datashare_name ADD TABLE schema.table`
+     *
+     * The schema must already have been added to the datashare (via
+     * `alterDatashareAddSchema`) before tables within it can be added.
+     */
+    alterDatashareAddTable(datashareName: string, schemaName: string, tableName: string): Promise<QueryResult>;
+    /**
+     * `GRANT USAGE ON DATASHARE datashare_name TO NAMESPACE 'guid' | ACCOUNT 'accountnumber' [VIA DATA CATALOG]`
+     *
+     * Grants a consumer (another namespace in the same account, or an entire
+     * other AWS account) read-only access to the datashare. The caller must
+     * already have been granted the `SHARE` permission on the datashare (via
+     * `GRANT SHARE ON DATASHARE ... TO ...`) unless they're the owner/superuser.
+     */
+    grantDatashareUsage(datashareName: string, target: DatashareGrantTarget): Promise<QueryResult>;
+    /**
+     * Consumer-side: `CREATE DATABASE db_name [WITH PERMISSIONS] FROM DATASHARE
+     * datashare_name OF [ACCOUNT account_id] NAMESPACE namespace_guid`
+     *
+     * Creates a local database backed by a datashare a producer has granted
+     * this cluster/namespace `USAGE` on. Only one consumer database can be
+     * created per datashare on a given cluster.
+     */
+    createDatabaseFromDatashare(dbName: string, datashareName: string, fromNamespace: string, options?: CreateDatabaseFromDatashareOptions): Promise<QueryResult>;
+    /**
+     * `CREATE EXTERNAL SCHEMA [IF NOT EXISTS] schema_name FROM POSTGRES|MYSQL
+     * DATABASE 'db' [SCHEMA 'schema'] URI 'host' [PORT n] IAM_ROLE 'role'
+     * SECRET_ARN 'arn'`
+     *
+     * `options.schema` is only valid (and only emitted) for `POSTGRES` -
+     * Redshift federated queries to MySQL don't support a separate schema
+     * namespace.
+     */
+    createExternalSchemaFederated(schemaName: string, options: ExternalSchemaFederatedOptions): Promise<QueryResult>;
+    showTables(): Promise<string[]>;
+    /**
+     * Show constraints for a table. Remember: any FK/UNIQUE/PK rows returned
+     * here describe DECLARED, not ENFORCED, constraints in Redshift.
+     */
+    showConstraints(tableName: string): Promise<any[]>;
+    /**
+     * Add a constraint. NOTE: Redshift accepts PRIMARY KEY/UNIQUE/FOREIGN KEY
+     * here but never enforces them (see class doc comment). CHECK constraints
+     * are rejected outright since Redshift has no CHECK constraint support.
+     */
+    addConstraint(tableName: string, options: {
+        type: 'UNIQUE' | 'CHECK' | 'PRIMARY KEY' | 'FOREIGN KEY';
+        fields: string[];
+        name?: string;
+        references?: {
+            table: string;
+            fields: string[];
+        };
+        check?: string;
+    }): Promise<void>;
+    removeConstraint(tableName: string, constraintName: string): Promise<void>;
+    createConstraint(tableName: string, constraintDef: ConstraintDefinition): Promise<void>;
+    dropConstraint(tableName: string, constraintName: string, options?: DropConstraintOptions): Promise<void>;
+    describeTable(tableName: string): Promise<TableDescription>;
+    renameTable(oldName: string, newName: string): Promise<void>;
+    changeOwner(newOwner: string, tableName: string): Promise<void>;
+    private noIndexSupport;
+    showIndexes(_tableName: string): Promise<any[]>;
+    addIndex(_tableName: string, _indexName: string, _fields?: string[], _options?: IndexOptions): Promise<void>;
+    removeIndex(_tableName: string, _indexName: string): Promise<void>;
+    createIndex(_tableName: string, _indexDef: IndexDefinition): Promise<void>;
+    dropIndex(_tableName: string, _indexName: string, _options?: DropIndexOptions): Promise<void>;
+    createFulltextIndex(): Promise<void>;
+    createSpatialIndex(): Promise<void>;
+    createPartialIndex(): Promise<void>;
+    createExpressionIndex(): Promise<void>;
+    private noFdwSupport;
+    createForeignDataWrapper(): Promise<void>;
+    dropForeignDataWrapper(): Promise<void>;
+    createForeignServer(): Promise<void>;
+    dropForeignServer(): Promise<void>;
+    createForeignTable(): Promise<void>;
+    buildCreateServerQuery(_name: string, _opts: FdwForeignServerOptions): string;
+    buildAlterServerQuery(_name: string, _opts: FdwAlterForeignServerOptions): string;
+    buildDropServerQuery(_name: string, _opts?: {
+        ifExists?: boolean;
+        cascade?: boolean;
+    }): string;
+    buildCreateUserMappingQuery(_opts: FdwUserMappingOptions): string;
+    buildAlterUserMappingQuery(_opts: FdwUserMappingOptions): string;
+    buildDropUserMappingQuery(_serverName: string, _user: string, _opts?: {
+        ifExists?: boolean;
+    }): string;
+    createUserMapping(): Promise<void>;
+    dropUserMapping(): Promise<void>;
+    buildCreateForeignTableQuery(_tableName: string, _opts: FdwForeignTableOptions): string;
+    buildDropForeignTableQuery(_tableName: string, _opts?: {
+        ifExists?: boolean;
+        cascade?: boolean;
+    }): string;
+    buildImportForeignSchemaQuery(_remoteSchema: string, _serverName: string, _opts?: FdwImportForeignSchemaOptions): string;
+    getServersQuery(): string;
+    createSecurityPolicy(): Promise<void>;
+    dropSecurityPolicy(): Promise<void>;
+    createPolicy(_options: PolicyOptions): Promise<void>;
+    dropPolicy(_policyName: string, _tableName: string, _options?: DropPolicyOptions): Promise<void>;
+    enableRLS(): Promise<void>;
+    disableRLS(): Promise<void>;
+    hasPolicy(): Promise<boolean>;
+    private noSequenceSupport;
+    createSequence(_options: SequenceOptions): Promise<void>;
+    dropSequence(_sequenceName: string, _options?: DropSequenceOptions): Promise<void>;
+    nextSequenceValue(_sequenceName: string): Promise<number>;
+    hasSequence(_sequenceName: string): Promise<boolean>;
+    listSequences(): Promise<string[]>;
+    createTrigger(_options: TriggerOptions): Promise<void>;
+    dropTrigger(_triggerName: string, _tableName: string, _options?: DropTriggerOptions): Promise<void>;
+    hasTrigger(): Promise<boolean>;
+    createIdentityColumn(): Promise<void>;
+    createComputedColumn(): Promise<void>;
+    commentTable(tableName: string, comment: string): Promise<void>;
+    commentColumn(tableName: string, columnName: string, comment: string): Promise<void>;
+    createStoredProcedure(options: StoredProcedureOptions): Promise<void>;
+    createProcedure(options: StoredProcedureOptions): Promise<void>;
+    dropStoredProcedure(procedureName: string, options?: DropStoredProcedureOptions): Promise<void>;
+    dropProcedure(procedureName: string, options?: DropStoredProcedureOptions): Promise<void>;
+    executeStoredProcedure(options: ExecuteStoredProcedureOptions): Promise<QueryResult>;
+    hasStoredProcedure(procedureName: string, schema?: string): Promise<boolean>;
+    /**
+     * Run Redshift's `VACUUM` maintenance command, which resorts rows within
+     * sort key order and reclaims space from deleted rows. Neither of these
+     * happen automatically the way Postgres's autovacuum does.
+     *
+     * Builds: `VACUUM [FULL|SORT ONLY|DELETE ONLY|REINDEX] [<table>] [TO <n> PERCENT] [BOOST]`
+     */
+    vacuum(tableName?: string, options?: RedshiftVacuumOptions): Promise<QueryResult>;
+    /**
+     * Run Redshift's `ANALYZE` maintenance command to refresh planner
+     * statistics (or `ANALYZE COMPRESSION` to get column encoding
+     * recommendations). Redshift's query planner relies entirely on these
+     * explicitly-collected stats; there is no background stats collector like
+     * Postgres's autovacuum/autoanalyze.
+     *
+     * Builds: `ANALYZE [<table> [(<col>, ...)]] [PREDICATE COLUMNS]`
+     */
+    analyze(tableName?: string, options?: RedshiftAnalyzeOptions): Promise<QueryResult>;
+    /**
+     * Run Redshift's `ANALYZE COMPRESSION` command, which samples a table (or
+     * the whole database when `tableName` is omitted) and recommends column
+     * encodings. This is a separate command from `ANALYZE` in Redshift - it
+     * does not update planner statistics, it only reports encoding advice.
+     */
+    analyzeCompression(tableName?: string): Promise<QueryResult>;
+    /**
+     * Redshift only supports two isolation levels: READ COMMITTED (the
+     * default) and SERIALIZABLE. Unlike Postgres, it has no MVCC snapshot
+     * mode equivalent to REPEATABLE READ, and no dirty-read mode (READ
+     * UNCOMMITTED). Requesting either of those would silently give the caller
+     * a *different, unrequested* isolation guarantee if we just ignored the
+     * option, so both are rejected outright instead.
+     */
+    private static readonly SUPPORTED_ISOLATION_LEVELS;
+    private getIsolationLevelSql;
+    startTransaction(options?: TransactionOptions): Promise<Transaction>;
+    commitTransaction(transaction: Transaction): Promise<void>;
+    rollbackTransaction(transaction: Transaction): Promise<void>;
+    /**
+     * Get the SQL for a data type.
+     *
+     * Notably: Redshift has no native JSON/JSONB type (that only exists in
+     * Postgres). Both `JSON` and `JSONB` DataTypes map to Redshift's
+     * semi-structured `SUPER` type instead.
+     */
+    getDataTypeSql(dataType: DataType): string;
+    buildWhereClause(where: WhereOptions, _options?: {
+        replacements?: Record<string, unknown>;
+    }): {
+        sql: string;
+        values: unknown[];
+    };
+    buildOrderClause(order: Order, _options?: {
+        replacements?: Record<string, unknown>;
+    }): string;
+    buildLimitOffset(limit?: number | string, offset?: number | string): string;
+    buildInsertQuery(tableName: string, values: Record<string, unknown>, options?: InsertOptions): {
+        sql: string;
+        values: unknown[];
+    };
+    /**
+     * Generate a collision-resistant temp/staging table name.
+     *
+     * Previously this used `${tableName}_staging_${Date.now()}` — millisecond
+     * wall-clock time only, with no randomness. Two concurrent upserts against
+     * the same table within the same millisecond (realistic under load, or in
+     * a tight parallel batch) would produce an identical staging table name.
+     * A random component (via `generateShortUUID()`) makes collisions
+     * practically impossible even when many upserts race within the same
+     * millisecond, on the same connection, or across processes/hosts.
+     *
+     * Also guards against exceeding Redshift's 127-byte identifier limit by
+     * truncating the base table name portion if necessary.
+     */
+    private generateStagingTableName;
+    /**
+     * Build an UPSERT "query" for Redshift.
+     *
+     * Why not `ON CONFLICT ... DO UPDATE` (what the Postgres dialect uses)?
+     * Redshift has never supported `ON CONFLICT` — it is a Postgres 9.5+
+     * feature, and Redshift's SQL layer, forked from Postgres 8.0, does not
+     * have it. Attempting to send `ON CONFLICT` SQL to a real Redshift cluster
+     * fails with a syntax error.
+     *
+     * Two strategies are available:
+     *
+     * 1. (default) AWS's documented "merge by replacing existing rows"
+     *    staging-table pattern, which works on every Redshift version:
+     *      a. Load the new/changed row(s) into a staging table (temp table
+     *         with the same shape as the target).
+     *      b. `DELETE FROM target USING staging WHERE target.<key> = staging.<key>`
+     *         to remove rows that are about to be replaced.
+     *      c. `INSERT INTO target SELECT * FROM staging` to insert the new
+     *         versions (and any brand new rows).
+     *
+     * 2. (opt-in via `options.useMerge`) A native `MERGE INTO ... USING ...
+     *    WHEN MATCHED THEN UPDATE ... WHEN NOT MATCHED THEN INSERT ...`
+     *    statement. Redshift only added `MERGE` support in 2023, so this is
+     *    NOT the default (it would fail with a syntax error on older/still-
+     *    common cluster versions) — set `options.useMerge: true` only when you
+     *    know the target cluster supports it. It has the advantage of being a
+     *    single atomic statement with no staging table required at all.
+     *
+     * IMPORTANT — atomicity: the staging-table strategy is inherently multiple
+     * statements (not a single parameterized `INSERT`), so the returned `sql`
+     * is a semicolon-separated multi-statement string. Running these
+     * statements one at a time through a connection pool (rather than a single
+     * pinned connection wrapped in `BEGIN`/`COMMIT`) risks the temp table
+     * created by statement 1 not being visible to later statements (temp
+     * tables are session-scoped), and leaves no rollback path if a
+     * mid-sequence statement fails. Use `upsert()` (below), which pins a
+     * single connection and wraps the whole sequence in an explicit
+     * transaction, rather than sending this string through the pooled
+     * `query()` method directly.
+     */
+    buildUpsertQuery(tableName: string, values: Record<string, unknown>, options?: UpsertQueryOptions & RedshiftUpsertOptions): {
+        sql: string;
+        values: unknown[];
+    };
+    /**
+     * Bulk variant of `buildUpsertQuery`: accepts an array of rows and builds
+     * ONE staging table populated with a single multi-row `INSERT`, rather
+     * than requiring one `buildUpsertQuery`/`upsert` call per row.
+     *
+     * This matches how the staging-table pattern is actually used in
+     * production Redshift pipelines — AWS documents it primarily as a *bulk*
+     * upsert technique (commonly fed by a `COPY` into the staging table for
+     * very large batches), so a single-row-only implementation undermines the
+     * main reason to prefer it over row-by-row `INSERT`/`UPDATE`.
+     *
+     * Not part of the `Dialect` interface (whose `buildUpsertQuery` takes a
+     * single `Record`) — this is a Redshift-specific addition, similar to
+     * `copyFromS3`.
+     */
+    buildBulkUpsertQuery(tableName: string, rows: Record<string, unknown>[], options?: UpsertQueryOptions & RedshiftUpsertOptions): {
+        sql: string;
+        values: unknown[];
+    };
+    /**
+     * Build a native `MERGE INTO` statement (Redshift 2023+ only). Shared by
+     * the single-row and bulk upsert paths — `columnsPerRow` is one entry per
+     * incoming row (all rows are expected to share the same column set).
+     */
+    private buildMergeStatement;
+    /**
+     * Execute a single-row upsert against Redshift, pinning ONE connection for
+     * the whole multi-statement sequence and wrapping it in an explicit
+     * `BEGIN`/`COMMIT` (`ROLLBACK` on any failure). This is the fix for the
+     * correctness bug in the raw `buildUpsertQuery()` string: sending that
+     * string's statements through the pooled `query()` method one at a time
+     * can land different statements on different physical connections (temp
+     * tables are session-scoped in Redshift, so the staging table created in
+     * statement 1 may not exist by the time statement 3 runs), and gives no
+     * atomicity/rollback if a statement mid-sequence fails.
+     *
+     * When `options.useMerge` is set, this still pins a connection and wraps
+     * the (single) `MERGE` statement in `BEGIN`/`COMMIT` for a consistent
+     * calling convention, even though a single statement is already atomic on
+     * its own.
+     */
+    upsert(tableName: string, values: Record<string, unknown>, options?: UpsertQueryOptions & RedshiftUpsertOptions): Promise<QueryResult>;
+    /**
+     * Bulk counterpart to `upsert()`: builds one staging-table (or `MERGE`)
+     * statement sequence for the whole `rows` array via `buildBulkUpsertQuery`,
+     * then runs it on a single pinned connection inside an explicit
+     * transaction, exactly like `upsert()`.
+     */
+    bulkUpsert(tableName: string, rows: Record<string, unknown>[], options?: UpsertQueryOptions & RedshiftUpsertOptions): Promise<QueryResult>;
+    /**
+     * Shared execution path for `upsert()`/`bulkUpsert()`: pins a single
+     * client from the pool, runs `BEGIN`, then each `;`-separated statement in
+     * `sql` in order (substituting `params` into only the first statement that
+     * needs them, i.e. the staging-table INSERT or the MERGE's USING clause),
+     * then `COMMIT`. Any failure triggers `ROLLBACK` before re-throwing, and
+     * the client is always released back to the pool.
+     */
+    private runUpsertStatements;
+    buildIncrementQuery(tableName: string, fields: string | string[] | Record<string, number>, where: WhereOptions, options?: {
+        by?: number;
+    }): {
+        sql: string;
+        values: unknown[];
+    };
+    buildUpdateQuery(tableName: string, values: Record<string, unknown>, where: WhereOptions, options?: DUpdateOptions): {
+        sql: string;
+        values: unknown[];
+    };
+    buildDeleteQuery(tableName: string, where: WhereOptions, options?: DeleteOptions): {
+        sql: string;
+        values: unknown[];
+    };
+    /**
+     * Format a single SELECT-list attribute into SQL.
+     *
+     * `options.attributes` isn't limited to plain column-name strings: the
+     * typed window-function builder library (`src/query-builders/functions/
+     * window.ts`, e.g. `rowNumber().partitionBy(...).as('rn')`) and the
+     * `fn()`/`col()`/`literal()`/`cast()`/`extract()` helpers in
+     * `src/operators.ts` all resolve to either a raw `LiteralExpression`
+     * (`{ __type: 'literal', sql }`) or a `[expression, alias]` tuple.
+     *
+     * Blindly calling `escapeId()` on those (as this method used to do) is
+     * broken: `escapeId` stringifies whatever it's given and wraps it in
+     * double quotes, so a tuple like `[literalExpr('ROW_NUMBER() OVER (...)'),
+     * 'rn']` became the identifier `"[object Object],rn"` instead of
+     * `ROW_NUMBER() OVER (...) AS "rn"`. This mirrors the attribute-resolution
+     * logic in `SqlCompiler.attributeToSqlWithAlias`/`processAttribute`
+     * (`src/query-builders/sql-compiler.ts`), but is implemented locally so it
+     * always renders identifiers via this dialect's own `escapeId`.
+     */
+    private formatSelectAttribute;
+    /**
+     * Build a `WITH [RECURSIVE] name [(cols)] AS (query), ...` prefix from
+     * `options.cte`.
+     *
+     * Each entry's `query` may be a raw SQL string, or a nested `SelectOptions`
+     * object (compiled recursively via `buildSelectQuery`); nested `SelectOptions`
+     * CTE bodies never carry positional parameter values of their own in this
+     * dialect - callers needing bound values in a CTE body should pass a raw
+     * SQL string with the values already inlined/escaped, or use `Literal`.
+     *
+     * If any entry sets `recursive: true`, the WHOLE clause is emitted as
+     * `WITH RECURSIVE` - Redshift, like Postgres and most other engines,
+     * applies `RECURSIVE` to the entire `WITH` clause rather than per-CTE.
+     *
+     * NOTE on version support: Amazon Redshift only added `WITH RECURSIVE`
+     * support relatively recently (RA3 node types on a sufficiently current
+     * maintenance track); clusters on older node types/tracks will reject
+     * `WITH RECURSIVE` with a syntax error even though plain (non-recursive)
+     * `WITH` CTEs have always been supported. This method does not attempt to
+     * detect the cluster's capabilities - it emits `WITH RECURSIVE` whenever
+     * asked and leaves it to the caller to know their cluster supports it.
+     */
+    private buildCteClause;
+    buildSelectQuery(options: SelectOptions): {
+        sql: string;
+        values: unknown[];
+    };
+    replaceReplacements(sql: string, replacements?: Record<string, unknown> | unknown[]): string;
+    buildCreateUserQuery(username: string, options?: any): string;
+    buildAlterUserQuery(username: string, options: any): string;
+    buildDropUserQuery(username: string, options?: any): string;
+    getUsersQuery(): string;
+    createUser(username: string, options?: Record<string, any>): Promise<void>;
+    buildGrantQuery(_options: any): string;
+    buildRevokeQuery(_options: any): string;
+    buildShowGrantsQuery(_username: string, _host?: string): string;
+    buildFlushPrivilegesQuery(): string;
+    buildCreateRoleQuery(_roleName: string, _options?: any): string;
+    buildDropRoleQuery(_roleName: string, _options?: any): string;
+    buildGrantRoleQuery(_role: string, _to: any, _options?: any): string;
+    buildRevokeRoleQuery(_role: string, _from: any, _options?: any): string;
+    getRolesQuery(): string;
+    /**
+     * Build a JSON_TABLE-equivalent expression to shred a JSON array into relational rows.
+     * Not supported: Redshift has no `JSON_TABLE`, no `OPENJSON`, and no
+     * `json_to_recordset`/`jsonb_to_recordset` (it has no JSONB type at all — JSON is
+     * mapped to the `SUPER` type, see `getDataTypeSql`). Redshift's real answer to
+     * shredding nested/array `SUPER` data is `UNNEST`/implicit lateral unnest over a
+     * `SUPER` column already stored in a table, not a general `(json, path) => rows`
+     * function that can operate on an arbitrary JSON expression, so it cannot be exposed
+     * through this API shape.
+     */
+    buildJsonTable(_jsonExpression: string, _rowPath: string, _columns: Array<{
+        name: string;
+        type?: string;
+        path?: string;
+        forOrdinality?: boolean;
+    }>, _alias: string): string;
+}
+/**
+ * Transaction handle for Redshift, backed by a single pooled `pg` client.
+ */
+export declare class RedshiftTransaction implements Transaction {
+    id: string;
+    finished: boolean;
+    options: TransactionOptions;
+    parent: Transaction | null;
+    savepoints: string[];
+    client: PoolClient | null;
+    private savepointCount;
+    constructor(client: PoolClient, _depth: number, options?: TransactionOptions);
+    createSavepoint(name?: string): Promise<string>;
+    rollbackToSavepoint(name: string): Promise<void>;
+    releaseSavepoint(name: string): Promise<void>;
+    commit(): Promise<void>;
+    rollback(): Promise<void>;
+}
+export interface RedshiftDialectOptions extends DialectOptions {
+    host?: string;
+    port?: number;
+    database?: string;
+    username?: string;
+    password?: string;
+    ssl?: any;
+    max?: number;
+    idleTimeoutMillis?: number;
+    connectionTimeoutMillis?: number;
+    statementTimeout?: number;
+    queryTimeout?: number;
+    /** Default DISTKEY to use for tables created without an explicit distKey. */
+    distKey?: string;
+    /** Default SORTKEY to use for tables created without an explicit sortKey. */
+    sortKey?: string | string[];
+}
+/**
+ * Create a new Redshift dialect instance.
+ */
+export declare function createRedshiftDialect(options?: RedshiftDialectOptions): RedshiftDialect;
+export default RedshiftDialect;