From e368fdeef870571007247c657a71b5d8d40e1e87 Mon Sep 17 00:00:00 2001 From: Ryan Kuo Date: Mon, 8 Dec 2025 15:40:29 -0500 Subject: [PATCH 1/3] correct & update example to add/drop constraint --- src/current/v23.2/alter-table.md | 73 +++++++++++-------------- src/current/v24.1/alter-table.md | 80 ++++++++++++++------------- src/current/v24.2/alter-table.md | 80 ++++++++++++++------------- src/current/v24.3/alter-table.md | 80 ++++++++++++++------------- src/current/v25.1/alter-table.md | 80 ++++++++++++++------------- src/current/v25.2/alter-table.md | 80 ++++++++++++++------------- src/current/v25.3/alter-table.md | 92 ++++++++++++++++++-------------- src/current/v25.4/alter-table.md | 92 ++++++++++++++++++-------------- src/current/v26.1/alter-table.md | 92 ++++++++++++++++++-------------- 9 files changed, 383 insertions(+), 366 deletions(-) diff --git a/src/current/v23.2/alter-table.md b/src/current/v23.2/alter-table.md index d374d303954..0376bd1d87c 100644 --- a/src/current/v23.2/alter-table.md +++ b/src/current/v23.2/alter-table.md @@ -1153,71 +1153,66 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; - ~~~ - - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ -1. View the table structure: +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1828,10 +1823,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v24.1/alter-table.md b/src/current/v24.1/alter-table.md index 30192484011..db8aa8c12ba 100644 --- a/src/current/v24.1/alter-table.md +++ b/src/current/v24.1/alter-table.md @@ -1142,71 +1142,73 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ - -1. View the table structure: +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1817,10 +1819,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v24.2/alter-table.md b/src/current/v24.2/alter-table.md index 3595a373921..8f403e7e99b 100644 --- a/src/current/v24.2/alter-table.md +++ b/src/current/v24.2/alter-table.md @@ -1115,71 +1115,73 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ - -1. View the table structure: +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1790,10 +1792,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v24.3/alter-table.md b/src/current/v24.3/alter-table.md index 30192484011..db8aa8c12ba 100644 --- a/src/current/v24.3/alter-table.md +++ b/src/current/v24.3/alter-table.md @@ -1142,71 +1142,73 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ - -1. View the table structure: +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1817,10 +1819,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v25.1/alter-table.md b/src/current/v25.1/alter-table.md index 7d4cd6ba99f..add9aaeadd6 100644 --- a/src/current/v25.1/alter-table.md +++ b/src/current/v25.1/alter-table.md @@ -1113,71 +1113,73 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ - -1. View the table structure: +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1773,10 +1775,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v25.2/alter-table.md b/src/current/v25.2/alter-table.md index a952ea00636..ca6a2420caa 100644 --- a/src/current/v25.2/alter-table.md +++ b/src/current/v25.2/alter-table.md @@ -1203,71 +1203,73 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ - -1. View the table structure: +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1869,10 +1871,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v25.3/alter-table.md b/src/current/v25.3/alter-table.md index 9f0679c48c0..2d5d22d11a0 100644 --- a/src/current/v25.3/alter-table.md +++ b/src/current/v25.3/alter-table.md @@ -1203,71 +1203,87 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) WITH (schema_locked = true); (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. The table is [schema-locked]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), which means schema changes are disallowed on the table. To make [DDL]({% link {{ page.version.version }}/sql-statements.md %}#data-definition-statements) changes, unlock the table: + + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes SET (schema_locked = false); + ~~~ + +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ +1. Re-enable `schema_locked` on the table: -1. View the table structure: + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes SET (schema_locked = true); + ~~~ + +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) WITH (schema_locked = true); + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1863,10 +1879,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v25.4/alter-table.md b/src/current/v25.4/alter-table.md index d87e7812434..09bf6cf535e 100644 --- a/src/current/v25.4/alter-table.md +++ b/src/current/v25.4/alter-table.md @@ -1203,71 +1203,87 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) WITH (schema_locked = true); (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. The table is [schema-locked]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), which means schema changes are disallowed on the table. To make [DDL]({% link {{ page.version.version }}/sql-statements.md %}#data-definition-statements) changes, unlock the table: + + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes SET (schema_locked = false); + ~~~ + +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ +1. Re-enable `schema_locked` on the table: -1. View the table structure: + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes SET (schema_locked = true); + ~~~ + +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) WITH (schema_locked = true); + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1863,10 +1879,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: diff --git a/src/current/v26.1/alter-table.md b/src/current/v26.1/alter-table.md index d87e7812434..09bf6cf535e 100644 --- a/src/current/v26.1/alter-table.md +++ b/src/current/v26.1/alter-table.md @@ -1203,71 +1203,87 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). {% include_cached copy-clipboard.html %} ~~~ sql -> SHOW CREATE TABLE users; +SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement --------------+-------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT users_pkey PRIMARY KEY (city ASC, id ASC) - | ) + table_name | create_statement +--------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) WITH (schema_locked = true); (1 row) ~~~ -1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `name` column with [`ALTER COLUMN`](#alter-column). +1. The table is [schema-locked]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), which means schema changes are disallowed on the table. To make [DDL]({% link {{ page.version.version }}/sql-statements.md %}#data-definition-statements) changes, unlock the table: + + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes SET (schema_locked = false); + ~~~ + +1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): {% include_cached copy-clipboard.html %} ~~~ sql - > ALTER TABLE users ALTER COLUMN name SET NOT NULL; + ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ +1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: + + {% include_cached copy-clipboard.html %} + ~~~ sql + SET autocommit_before_ddl = false; + ~~~ + 1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: {% include_cached copy-clipboard.html %} ~~~ sql - > BEGIN; - > ALTER TABLE users DROP CONSTRAINT "primary"; - > ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id); - > COMMIT; + BEGIN; + ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; + ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + COMMIT; ~~~ - ~~~ - NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes - ~~~ +1. Re-enable `schema_locked` on the table: -1. View the table structure: + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes SET (schema_locked = true); + ~~~ + +1. View the updated table structure: {% include_cached copy-clipboard.html %} ~~~ sql - > SHOW CREATE TABLE users; + SHOW CREATE TABLE promo_codes; ~~~ ~~~ - table_name | create_statement - -------------+--------------------------------------------------------------------- - users | CREATE TABLE users ( - | id UUID NOT NULL, - | city VARCHAR NOT NULL, - | name VARCHAR NOT NULL, - | address VARCHAR NULL, - | credit_card VARCHAR NULL, - | CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC), - | FAMILY "primary" (id, city, name, address, credit_card) - | ) - (1 row) + table_name | create_statement + --------------+---------------------------------------------------------------------------- + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NOT NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC, creation_time ASC) + | ) WITH (schema_locked = true); + (1 row) ~~~ -Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint. +Using [`ALTER PRIMARY KEY`]({% link {{ page.version.version }}/alter-table.md %}#alter-primary-key) would have created a `UNIQUE` secondary index called `promo_codes_code_key`. Instead, there is just one index for the primary key constraint. #### Add a unique index to a `REGIONAL BY ROW` table @@ -1863,10 +1879,6 @@ To unhide the column, run: ### Alter a primary key -#### Demo - -{% include_cached youtube.html video_id="MPx-LXY2D-c" %} - #### Alter a single-column primary key Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement: From cdeb201e9a55fc2e1b4876b28fe52612da28b7fa Mon Sep 17 00:00:00 2001 From: Ryan Kuo Date: Mon, 15 Dec 2025 16:41:30 -0500 Subject: [PATCH 2/3] update example to use a single implicit txn --- src/current/v23.2/alter-table.md | 57 +++++++++++++++------------- src/current/v24.1/alter-table.md | 56 ++++++++++++++-------------- src/current/v24.2/alter-table.md | 56 ++++++++++++++-------------- src/current/v24.3/alter-table.md | 56 ++++++++++++++-------------- src/current/v25.1/alter-table.md | 56 ++++++++++++++-------------- src/current/v25.2/alter-table.md | 56 ++++++++++++++-------------- src/current/v25.3/alter-table.md | 64 ++++++++++++++++---------------- src/current/v25.4/alter-table.md | 64 ++++++++++++++++---------------- src/current/v26.1/alter-table.md | 64 ++++++++++++++++---------------- 9 files changed, 262 insertions(+), 267 deletions(-) diff --git a/src/current/v23.2/alter-table.md b/src/current/v23.2/alter-table.md index 0376bd1d87c..f7b7deb5e1c 100644 --- a/src/current/v23.2/alter-table.md +++ b/src/current/v23.2/alter-table.md @@ -1153,26 +1153,28 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ +1. View the details of the `promo_codes` table: -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) -(1 row) -~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) + (1 row) + ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1181,15 +1183,18 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + ~~~ + + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. View the updated table structure: diff --git a/src/current/v24.1/alter-table.md b/src/current/v24.1/alter-table.md index db8aa8c12ba..31dc7775054 100644 --- a/src/current/v24.1/alter-table.md +++ b/src/current/v24.1/alter-table.md @@ -1142,26 +1142,28 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ +1. View the details of the `promo_codes` table: -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) -(1 row) -~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) + (1 row) + ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1170,22 +1172,18 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: - - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. View the updated table structure: diff --git a/src/current/v24.2/alter-table.md b/src/current/v24.2/alter-table.md index 8f403e7e99b..2a2bb72cab2 100644 --- a/src/current/v24.2/alter-table.md +++ b/src/current/v24.2/alter-table.md @@ -1115,26 +1115,28 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ +1. View the details of the `promo_codes` table: -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) -(1 row) -~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) + (1 row) + ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1143,22 +1145,18 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: - - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. View the updated table structure: diff --git a/src/current/v24.3/alter-table.md b/src/current/v24.3/alter-table.md index db8aa8c12ba..31dc7775054 100644 --- a/src/current/v24.3/alter-table.md +++ b/src/current/v24.3/alter-table.md @@ -1142,26 +1142,28 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ +1. View the details of the `promo_codes` table: -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) -(1 row) -~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) + (1 row) + ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1170,22 +1172,18 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: - - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. View the updated table structure: diff --git a/src/current/v25.1/alter-table.md b/src/current/v25.1/alter-table.md index add9aaeadd6..34d8d457995 100644 --- a/src/current/v25.1/alter-table.md +++ b/src/current/v25.1/alter-table.md @@ -1113,26 +1113,28 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ +1. View the details of the `promo_codes` table: -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) -(1 row) -~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) + (1 row) + ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1141,22 +1143,18 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: - - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. View the updated table structure: diff --git a/src/current/v25.2/alter-table.md b/src/current/v25.2/alter-table.md index ca6a2420caa..8bb08b8c17e 100644 --- a/src/current/v25.2/alter-table.md +++ b/src/current/v25.2/alter-table.md @@ -1203,26 +1203,28 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ +1. View the details of the `promo_codes` table: -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) -(1 row) -~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) + (1 row) + ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1231,22 +1233,18 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: - - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. View the updated table structure: diff --git a/src/current/v25.3/alter-table.md b/src/current/v25.3/alter-table.md index 2d5d22d11a0..b2ab953e84f 100644 --- a/src/current/v25.3/alter-table.md +++ b/src/current/v25.3/alter-table.md @@ -1203,32 +1203,27 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ - -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) WITH (schema_locked = true); -(1 row) -~~~ - -1. The table is [schema-locked]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), which means schema changes are disallowed on the table. To make [DDL]({% link {{ page.version.version }}/sql-statements.md %}#data-definition-statements) changes, unlock the table: +1. View the details of the `promo_codes` table: {% include_cached copy-clipboard.html %} ~~~ sql - ALTER TABLE promo_codes SET (schema_locked = false); + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) WITH (schema_locked = true); + (1 row) ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1238,22 +1233,27 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. The `promo_codes` table is schema-locked with the [`schema_locked` table parameter]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), and the `DROP CONSTRAINT` and `ADD CONSTRAINT` schema changes cannot automatically unset `schema_locked`. In this case, you must manually unlock the table with `schema_locked = false`, complete the schema change, and then lock the table again with `schema_locked = true`. + + Unlock the table: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes SET (schema_locked = false); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + ~~~ + + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. Re-enable `schema_locked` on the table: diff --git a/src/current/v25.4/alter-table.md b/src/current/v25.4/alter-table.md index 09bf6cf535e..aa3e4fe6484 100644 --- a/src/current/v25.4/alter-table.md +++ b/src/current/v25.4/alter-table.md @@ -1203,32 +1203,27 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ - -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) WITH (schema_locked = true); -(1 row) -~~~ - -1. The table is [schema-locked]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), which means schema changes are disallowed on the table. To make [DDL]({% link {{ page.version.version }}/sql-statements.md %}#data-definition-statements) changes, unlock the table: +1. View the details of the `promo_codes` table: {% include_cached copy-clipboard.html %} ~~~ sql - ALTER TABLE promo_codes SET (schema_locked = false); + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) WITH (schema_locked = true); + (1 row) ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1238,22 +1233,27 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. The `promo_codes` table is schema-locked with the [`schema_locked` table parameter]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), and the `DROP CONSTRAINT` and `ADD CONSTRAINT` schema changes cannot automatically unset `schema_locked`. In this case, you must manually unlock the table with `schema_locked = false`, complete the schema change, and then lock the table again with `schema_locked = true`. + + Unlock the table: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes SET (schema_locked = false); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + ~~~ + + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. Re-enable `schema_locked` on the table: diff --git a/src/current/v26.1/alter-table.md b/src/current/v26.1/alter-table.md index 09bf6cf535e..b4e6e7121bb 100644 --- a/src/current/v26.1/alter-table.md +++ b/src/current/v26.1/alter-table.md @@ -1203,32 +1203,27 @@ By default, referenced columns must be in the same database as the referencing f #### Drop and add a primary key constraint -Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). +Suppose that you want to add `creation_time` to the composite primary key of the `promo_codes` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key). To do so, use [`DROP CONSTRAINT`](#drop-constraint) and [`ADD CONSTRAINT`](#add-constraint) in a single `ALTER TABLE` statement. -{% include_cached copy-clipboard.html %} -~~~ sql -SHOW CREATE TABLE promo_codes; -~~~ - -~~~ - table_name | create_statement ---------------+------------------------------------------------------------ - promo_codes | CREATE TABLE public.promo_codes ( - | code VARCHAR NOT NULL, - | description VARCHAR NULL, - | creation_time TIMESTAMP NULL, - | expiration_time TIMESTAMP NULL, - | rules JSONB NULL, - | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) - | ) WITH (schema_locked = true); -(1 row) -~~~ - -1. The table is [schema-locked]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), which means schema changes are disallowed on the table. To make [DDL]({% link {{ page.version.version }}/sql-statements.md %}#data-definition-statements) changes, unlock the table: +1. View the details of the `promo_codes` table: {% include_cached copy-clipboard.html %} ~~~ sql - ALTER TABLE promo_codes SET (schema_locked = false); + SHOW CREATE TABLE promo_codes; + ~~~ + + ~~~ + table_name | create_statement + --------------+------------------------------------------------------------ + promo_codes | CREATE TABLE public.promo_codes ( + | code VARCHAR NOT NULL, + | description VARCHAR NULL, + | creation_time TIMESTAMP NULL, + | expiration_time TIMESTAMP NULL, + | rules JSONB NULL, + | CONSTRAINT promo_codes_pkey PRIMARY KEY (code ASC) + | ) WITH (schema_locked = true); + (1 row) ~~~ 1. Add a [`NOT NULL`]({% link {{ page.version.version }}/not-null.md %}) constraint to the `creation_time` column with [`ALTER COLUMN`](#alter-column): @@ -1238,22 +1233,27 @@ SHOW CREATE TABLE promo_codes; ALTER TABLE promo_codes ALTER COLUMN creation_time SET NOT NULL; ~~~ -1. Turn off autocommit for DDL for the current session, so that multiple DDL statements can execute within one explicit transaction: +1. The `promo_codes` table is schema-locked with the [`schema_locked` table parameter]({% link {{ page.version.version }}/with-storage-parameter.md %}#table-parameters), and the `DROP CONSTRAINT` and `ADD CONSTRAINT` schema changes cannot automatically unset `schema_locked`. In this case, you must manually unlock the table with `schema_locked = false`, complete the schema change, and then lock the table again with `schema_locked = true`. + + Unlock the table: {% include_cached copy-clipboard.html %} ~~~ sql - SET autocommit_before_ddl = false; + ALTER TABLE promo_codes SET (schema_locked = false); ~~~ -1. In the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](#add-constraint) the new one: +1. To issue the schema change atomically, use single statements as an implicit transaction. `DROP CONSTRAINT` and `ADD CONSTRAINT` can be combined in a single `ALTER TABLE` statement: - {% include_cached copy-clipboard.html %} - ~~~ sql - BEGIN; - ALTER TABLE promo_codes DROP CONSTRAINT promo_codes_pkey; - ALTER TABLE promo_codes ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); - COMMIT; - ~~~ + {% include_cached copy-clipboard.html %} + ~~~ sql + ALTER TABLE promo_codes + DROP CONSTRAINT promo_codes_pkey, + ADD CONSTRAINT promo_codes_pkey PRIMARY KEY (code, creation_time); + ~~~ + + {{site.data.alerts.callout_info}} + You should **not** execute the schema change with multiple statements within an explicit transaction. Refer to [Schema changes within transactions]({% link {{ page.version.version }}/online-schema-changes.md %}#schema-changes-within-transactions). + {{site.data.alerts.end}} 1. Re-enable `schema_locked` on the table: From 20adf9b5e7e0f8de7f9147fc329a5090e896ad61 Mon Sep 17 00:00:00 2001 From: Ryan Kuo Date: Mon, 15 Dec 2025 16:42:17 -0500 Subject: [PATCH 3/3] QoL tweaks to online schema changes doc --- src/current/v23.2/online-schema-changes.md | 2 +- src/current/v24.1/online-schema-changes.md | 2 +- src/current/v24.2/online-schema-changes.md | 6 ++++-- src/current/v25.1/online-schema-changes.md | 6 ++++-- src/current/v25.2/online-schema-changes.md | 6 ++++-- src/current/v25.3/online-schema-changes.md | 6 ++++-- src/current/v25.4/online-schema-changes.md | 6 ++++-- src/current/v26.1/online-schema-changes.md | 6 ++++-- 8 files changed, 26 insertions(+), 14 deletions(-) diff --git a/src/current/v23.2/online-schema-changes.md b/src/current/v23.2/online-schema-changes.md index 85840ac932f..81e5ae9aa14 100644 --- a/src/current/v23.2/online-schema-changes.md +++ b/src/current/v23.2/online-schema-changes.md @@ -181,7 +181,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v24.1/online-schema-changes.md b/src/current/v24.1/online-schema-changes.md index 7c8ec88ba25..e021c0a2835 100644 --- a/src/current/v24.1/online-schema-changes.md +++ b/src/current/v24.1/online-schema-changes.md @@ -181,7 +181,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v24.2/online-schema-changes.md b/src/current/v24.2/online-schema-changes.md index 9624b8c3119..b566a71ece2 100644 --- a/src/current/v24.2/online-schema-changes.md +++ b/src/current/v24.2/online-schema-changes.md @@ -19,7 +19,9 @@ Schema changes consume additional resources, and if they are run when the cluste {{site.data.alerts.end}} {{site.data.alerts.callout_info}} -CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction.

Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). +CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction. + +Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). {{site.data.alerts.end}} ## How online schema changes work @@ -181,7 +183,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v25.1/online-schema-changes.md b/src/current/v25.1/online-schema-changes.md index 395d6c3b920..e2b5d79529a 100644 --- a/src/current/v25.1/online-schema-changes.md +++ b/src/current/v25.1/online-schema-changes.md @@ -19,7 +19,9 @@ Schema changes consume additional resources, and if they are run when the cluste {{site.data.alerts.end}} {{site.data.alerts.callout_info}} -CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction.

Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). +CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction. + +Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). {{site.data.alerts.end}} ## How online schema changes work @@ -181,7 +183,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v25.2/online-schema-changes.md b/src/current/v25.2/online-schema-changes.md index 395d6c3b920..e2b5d79529a 100644 --- a/src/current/v25.2/online-schema-changes.md +++ b/src/current/v25.2/online-schema-changes.md @@ -19,7 +19,9 @@ Schema changes consume additional resources, and if they are run when the cluste {{site.data.alerts.end}} {{site.data.alerts.callout_info}} -CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction.

Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). +CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction. + +Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). {{site.data.alerts.end}} ## How online schema changes work @@ -181,7 +183,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v25.3/online-schema-changes.md b/src/current/v25.3/online-schema-changes.md index 395d6c3b920..e2b5d79529a 100644 --- a/src/current/v25.3/online-schema-changes.md +++ b/src/current/v25.3/online-schema-changes.md @@ -19,7 +19,9 @@ Schema changes consume additional resources, and if they are run when the cluste {{site.data.alerts.end}} {{site.data.alerts.callout_info}} -CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction.

Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). +CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction. + +Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). {{site.data.alerts.end}} ## How online schema changes work @@ -181,7 +183,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v25.4/online-schema-changes.md b/src/current/v25.4/online-schema-changes.md index 395d6c3b920..e2b5d79529a 100644 --- a/src/current/v25.4/online-schema-changes.md +++ b/src/current/v25.4/online-schema-changes.md @@ -19,7 +19,9 @@ Schema changes consume additional resources, and if they are run when the cluste {{site.data.alerts.end}} {{site.data.alerts.callout_info}} -CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction.

Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). +CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction. + +Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). {{site.data.alerts.end}} ## How online schema changes work @@ -181,7 +183,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs diff --git a/src/current/v26.1/online-schema-changes.md b/src/current/v26.1/online-schema-changes.md index 395d6c3b920..e2b5d79529a 100644 --- a/src/current/v26.1/online-schema-changes.md +++ b/src/current/v26.1/online-schema-changes.md @@ -19,7 +19,9 @@ Schema changes consume additional resources, and if they are run when the cluste {{site.data.alerts.end}} {{site.data.alerts.callout_info}} -CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction.

Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). +CockroachDB [does not support schema changes within explicit transactions](#schema-changes-within-transactions) with full atomicity guarantees. CockroachDB only supports DDL changes within implicit transactions (individual statements). If a schema management tool uses transactions on your behalf, it should only execute one schema change operation per transaction. + +Some tools and applications may be able to workaround CockroachDB's lack of transactional schema changes by [enabling a setting that automatically commits before running schema changes inside transactions](#enable-automatic-commit-before-running-schema-changes-inside-transactions). {{site.data.alerts.end}} ## How online schema changes work @@ -181,7 +183,7 @@ COMMIT ### Run multiple schema changes in a single `ALTER TABLE` statement -Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}). For a demonstration, see [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically). +Some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, refer to [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}#subcommands). For examples, refer to [Add and rename columns atomically]({% link {{ page.version.version }}/alter-table.md %}#add-and-rename-columns-atomically) and [Drop and add a primary key constraint]({% link {{ page.version.version }}/alter-table.md %}#drop-and-add-a-primary-key-constraint). ### Show all schema change jobs