ALTER SOURCE
View as MarkdownUse ALTER SOURCE to:
- Add a subsource to a source.
- Refresh the upstream references available to a source.
- Rename a source.
- Change owner of a source.
- Change retain history configuration for the source.
- Change timestamp interval for the source.
Syntax
To add the specified upstream table(s) to the specified PostgreSQL/MySQL/SQL Server source:
ALTER SOURCE [IF EXISTS] <name>
ADD SUBSOURCE|TABLE <table> [AS <subsrc>] [, ...]
[WITH (<options>)]
;
| Syntax element | Description |
|---|---|
<name>
|
The name of the PostgreSQL/MySQL/SQL Server source you want to alter. |
<table>
|
The upstream table to add to the source. |
AS <subsrc>
|
Optional. The name for the subsource in Materialize. |
WITH (TEXT COLUMNS (<col> [, …]))
|
Optional. List of columns to decode as text for types that are unsupported in Materialize.
|
ALTER SOURCE ... ADD SUBSOURCE ...), Materialize starts the snapshotting
process for the new subsource. During this snapshotting, the data ingestion for
the existing subsources for the same source is temporarily blocked. As such, if
possible, you can resize the cluster to speed up the snapshotting process and
once the process finishes, resize the cluster for steady-state.
To refresh the list of upstream objects available to a source:
ALTER SOURCE [IF EXISTS] <name> REFRESH REFERENCES;
| Syntax element | Description |
|---|---|
<name>
|
The name of the source whose available upstream references you want to refresh. |
Refreshing references updates the upstream objects Materialize records for
the source in mz_internal.mz_source_references. It does not change the
data the source ingests. See Refreshing available upstream
references.
To rename a source:
ALTER SOURCE <name> RENAME TO <new_name>;
| Syntax element | Description |
|---|---|
<name>
|
The current name of the source you want to alter. |
<new_name>
|
The new name of the source. |
See also Renaming restrictions.
To change the owner of a source:
ALTER SOURCE <name> OWNER TO <new_owner_role>;
| Syntax element | Description |
|---|---|
<name>
|
The name of the source you want to change ownership of. |
<new_owner_role>
|
The new owner of the source. |
To change the owner of a source, you must be the owner of the source and have
membership in the <new_owner_role>. See also Privileges.
To set the retention history for a source:
ALTER SOURCE [IF EXISTS] <name> SET (RETAIN HISTORY [=] FOR <retention_period>);
| Syntax element | Description |
|---|---|
<name>
|
The name of the source you want to alter. |
<retention_period>
|
Private preview. This option has known performance or stability issues and is under active development. Duration for which Materialize retains historical data, which is useful to implement durable subscriptions. Accepts positive interval values (e.g. '1hr'). Default: 1s.
|
To reset the retention history to the default for a source:
ALTER SOURCE [IF EXISTS] <name> RESET (RETAIN HISTORY);
| Syntax element | Description |
|---|---|
<name>
|
The name of the source you want to alter. |
To set the timestamp interval for a source:
ALTER SOURCE [IF EXISTS] <name> SET (TIMESTAMP INTERVAL [=] <interval>);
| Syntax element | Description |
|---|---|
<name>
|
The name of the source you want to alter. |
<interval>
|
The interval at which timestamps are assigned to the data read from
this source. Accepts positive interval values
(e.g. '500ms', '1s'). The value must be between the system
parameters min_timestamp_interval and max_timestamp_interval.
Default: 1s.
|
To reset the timestamp interval to the system default for a source:
ALTER SOURCE [IF EXISTS] <name> RESET (TIMESTAMP INTERVAL);
| Syntax element | Description |
|---|---|
<name>
|
The name of the source you want to alter. |
Context
Adding subsources to a PostgreSQL/MySQL/SQL Server source
Note that using a combination of dropping and adding subsources lets you change the schema of the PostgreSQL/MySQL/SQL Server tables that are ingested.
ALTER SOURCE ... ADD SUBSOURCE ...), Materialize starts the snapshotting
process for the new subsource. During this snapshotting, the data ingestion for
the existing subsources for the same source is temporarily blocked. As such, if
possible, you can resize the cluster to speed up the snapshotting process and
once the process finishes, resize the cluster for steady-state.
Dropping subsources from a PostgreSQL/MySQL/SQL Server source
Dropping a subsource prevents Materialize from ingesting any data from it, in addition to dropping any state that Materialize previously had for the table (such as its contents).
If a subsource encounters a deterministic error, such as an incompatible schema change (e.g. dropping an ingested column), you can drop the subsource. If you want to ingest it with its new schema, you can then add it as a new subsource.
You cannot drop the “progress subsource”.
Refreshing available upstream references
When you create a source, Materialize records the objects that source could read
in mz_internal.mz_source_references. For a PostgreSQL, MySQL, or SQL Server
source, that list comes from querying the upstream database. Either way the list
is a snapshot taken at creation time, and Materialize does not update it as the
upstream changes. A table added to a PostgreSQL publication after the source was
created, for example, does not show up there.
ALTER SOURCE ... REFRESH REFERENCES recomputes that list and replaces the
recorded references for the source. Objects that have appeared since the last
refresh are added, and objects that no longer exist are removed.
Refreshing references only updates this metadata. It neither starts nor stops
ingesting anything. To ingest a newly available object, create a table from the
source with CREATE TABLE ... FROM SOURCE; to
stop ingesting one, drop the corresponding table.
The statement is accepted for any source that ingests from an external system, but what it recomputes depends on the source type:
| Source type | Effect of a refresh |
|---|---|
| PostgreSQL, MySQL, SQL Server | Queries the upstream database for the tables the source can read. |
| Kafka | No practical effect. The only reference is the topic the source was configured with. |
| Load generator | Re-reads the load generator’s built-in views, which change only when a Materialize upgrade adds views. |
Webhook sources, which are written to rather than read from, return an error.
For PostgreSQL, MySQL, and SQL Server sources, the refresh connects to the upstream database, so it fails if that database is unreachable or the source’s connection is no longer valid. For PostgreSQL sources, it also fails if the source’s publication is empty.
Examples
Adding subsources
ALTER SOURCE pg_src ADD SUBSOURCE tbl_a, tbl_b AS b WITH (TEXT COLUMNS [tbl_a.col]);
ALTER SOURCE ... ADD SUBSOURCE ...), Materialize starts the snapshotting
process for the new subsource. During this snapshotting, the data ingestion for
the existing subsources for the same source is temporarily blocked. As such, if
possible, you can resize the cluster to speed up the snapshotting process and
once the process finishes, resize the cluster for steady-state.
Dropping subsources
To drop a subsource, use the DROP SOURCE command:
DROP SOURCE tbl_a, b CASCADE;
Refreshing references
To refresh the upstream objects Materialize records for a source:
ALTER SOURCE pg_src REFRESH REFERENCES;
To then inspect the refreshed references:
SELECT refs.namespace, refs.name, refs.columns, refs.updated_at
FROM mz_internal.mz_source_references refs, mz_sources s
WHERE s.name = 'pg_src'
AND refs.source_id = s.id;
Changing the timestamp interval
To set a custom timestamp interval for a source:
ALTER SOURCE kafka_src SET (TIMESTAMP INTERVAL = '500ms');
To reset the timestamp interval to the system default:
ALTER SOURCE kafka_src RESET (TIMESTAMP INTERVAL);
Privileges
The privileges required to execute this statement are:
- Ownership of the source being altered.
- In addition, to change owners:
- Role membership in
new_owner. CREATEprivileges on the containing schema if the source is namespaced by a schema.
- Role membership in