Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198.
Existing Python UDFs will continue to function until June 30, 2026. For more information, see the
blog post
Altering table definitions
ALTER TABLE statements are used to change table definitions, including
schema, partition specs, and properties. You can use these DDL statements to manage your
Iceberg tables directly through Amazon Redshift.
All ALTER TABLE statements support using external schema references or
three-part notation references for Iceberg tables. In the syntax examples below,
can be any of the
following:iceberg_table
-- External schema notation:<external_schema>.<table_name>-- Three-part notation for S3 table buckets: "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>-- Three-part notation for the awsdatacatalog root catalog: awsdatacatalog.<database_name>.<table_name>
For more information, see Referencing Iceberg tables in Amazon Redshift.
Consider the following when using ALTER TABLE statements:
-
ALTER TABLEstatements currently only support Iceberg v2 tables. -
All
ALTER TABLEstatements are metadata-only operations. -
ALTER TABLEstatements don't support tables with complex type columns.
Contents
ALTER TABLE RENAME COLUMN
ALTER TABLEiceberg_tableRENAME [COLUMN]col_nameTOnew_name;
ALTER TABLE RENAME COLUMN renames an existing column. The
can be a partition column or a
non-partitioned column. After the rename, the column data type and partition spec don't
change.col_name
Note
ALTER TABLE RENAME COLUMN is not supported for AWS Lake Formation registered
tables.
ALTER TABLE ADD/DROP COLUMN
ALTER TABLEiceberg_tableADD [COLUMN]col_namecol_type;
ALTER TABLEiceberg_tableDROP [COLUMN]col_name;
ADD COLUMN adds one column to an existing Iceberg table. You can use any
data type that is supported by Amazon Redshift Iceberg writes. For more information, see Supported data types with Apache Iceberg tables.
ADD COLUMN is a metadata-only operation. The values of newly added
columns on existing rows are NULL.
DROP COLUMN drops a column from an existing Iceberg table. For
partitioned tables, you can't drop a column that belongs to the current partition spec.
You must remove the partition field that involves the column first before dropping the
column. For more information, see ALTER TABLE ADD, DROP, and REPLACE PARTITION FIELD.
ALTER TABLE ALTER COLUMN
ALTER TABLEiceberg_tableALTER COLUMNcolumn_nameTYPEupdated_data_type;
ALTER TABLE ALTER COLUMN changes the data type of an existing column.
Only type widening is allowed, not narrowing. Because data isn't rewritten after the
ALTER, narrowing data types could cause overflow when consuming the
existing table data. The following type widenings are allowed per the Iceberg spec:
int → bigint float → double decimal(P, S) → decimal(P2, S) where P2 > P (scale cannot be changed)
In Amazon Redshift, data types can have aliases. For example, 4-byte integers use the
type name int or int4. As long as they are mapped to
4-byte int in Iceberg types, type widening to 8-byte integers is allowed.
For example, an Iceberg table is created using 4-byte integer types:
CREATE TABLEiceberg_table(cint int) USING ICEBERG LOCATION 's3://your-bucket-name/prefix/';
It can be widened by this ALTER statement:
ALTER TABLEiceberg_tableALTER COLUMN cint TYPE int8;
For the full list of data type mappings between Amazon Redshift types and Iceberg types, see Supported data types with Apache Iceberg tables.
Widening the type of a column that belongs to the existing partition spec is not supported.
ALTER TABLE SET TABLE PROPERTIES
ALTER TABLEiceberg_tableSET TABLE PROPERTIES ( 'compression_type' = 'compression_value');
This statement allows you to overwrite the default table property. Currently the only
table property allowed for this statement is compression_type. You can
overwrite it to use a different compression type for the Iceberg table Parquet files.
Data inserted after the ALTER uses the new compression type.
The possible values for compression_type are: brotli,
gzip, snappy, uncompressed, and
zstd.
ALTER TABLE ADD, DROP, and REPLACE PARTITION FIELD
ALTER TABLEiceberg_tableADD PARTITION FIELDcolumn_name|transform_function;
ALTER TABLEiceberg_tableDROP PARTITION FIELDcolumn_name|transform_function;
ALTER TABLEiceberg_tableREPLACE PARTITION FIELDcolumn_name|transform_functionWITHcolumn_name|transform_function;
The [ADD | DROP | REPLACE] PARTITION FIELD statements allow you to change
the existing table partition spec, supporting partition evolution through
Amazon Redshift.
The ALTER statements for partition spec only change table metadata and
don't re-partition the existing table data. After the ALTER, new data
inserted into the table follows the newly defined partition spec.
Consider the following limitations for these statements:
-
When defining a new partition field through
ADDorREPLACE ... WITH ..., the new field can't include a column that's already part of other partition fields. This is the same limitation as when you define the initial partition spec atCREATE TABLE. For more information, see CREATE TABLE.For example, when you have a table:
CREATE TABLEiceberg_table... PARTITIONED BY year(ship_date) USING ICEBERG ...;The following fails because
ship_dateis already part of an existing partition field:ALTER TABLEiceberg_tableADD PARTITION FIELD bucket(128, ship_date); -
When adding a new partition field, the newly added field is always treated as the last level of partition of the table. For example:
CREATE TABLEiceberg_table... PARTITIONED BY year(ship_date) USING ICEBERG ...; ALTER TABLEiceberg_tableADD PARTITION FIELD bucket(256, item_id);The table partition spec is the same as:
CREATE TABLEiceberg_table... PARTITIONED BY (year(ship_date), bucket(256, item_id)) USING ICEBERG ...; -
When dropping a partition field, it's not limited to the last level of partition. You can drop any existing partition field. For example:
CREATE TABLEiceberg_table... PARTITIONED BY (year(ship_date), bucket(256, item_id)) USING ICEBERG ...; ALTER TABLEiceberg_tableDROP PARTITION FIELD year(ship_date);After this
ALTER, the table is only partitioned bybucket(256, item_id). -
When calling
REPLACE PARTITION FIELD ... WITH ..., the partition field to be replaced can be any field in the spec and is not limited to the last field. For example:CREATE TABLEiceberg_table... PARTITIONED BY (year(ship_date), bucket(256, item_id)) USING ICEBERG ...; ALTER TABLEiceberg_tableREPLACE PARTITION FIELD year(ship_date) WITH month(ship_date);After this
ALTER, the table partition becomes(month(ship_date), bucket(256, item_id)). -
The
voidtransform is not supported in partitionALTERstatements.