Merge remote-tracking branch 'origin/main' into DOC-10406

src/current/_data/releases.yml

@@ -6074,15 +6074,8 @@
   major_version: v24.1
   release_date: '2024-05-20'
   release_type: Production
-  cloud_only: true
-  cloud_only_message_short: 'Available in CockroachDB Dedicated. Self-hosted binaries <a href="https://www.cockroachlabs.com/docs/releases/v24.1#v24-1-0">available June 3, 2024</a> per the <a href="https://www.cockroachlabs.com/docs/releases/staged-release-process">staged release process</a>.'
-  cloud_only_message: >
-    CockroachDB v24.1 is now generally available for CockroachDB Dedicated,
-    and is scheduled to be made available for CockroachDB Self-Hosted on June 3, 2024 per the <a href="https://www.cockroachlabs.com/docs/releases/staged-release-process">staged release process</a>.
-    For more information, refer to
-    [Upgrade to CockroachDB v24.1](https://www.cockroachlabs.com/docs/cockroachcloud/upgrade-to-v24.1). To connect to a CockroachDB Dedicated cluster on v24.1, refer to [Connect to a CockroachDB Dedicated Cluster](https://www.cockroachlabs.com/docs/cockroachcloud/connect-to-your-cluster).
   go_version: go1.22.0
-  sha: 6205244e922606f85761dad2137b842f43a53716
+  sha: 5e4ca9e26f1a25681de9c944298cfa139c344466
   has_sql_only: true
   has_sha256sum: true
   mac:
@@ -6097,7 +6090,7 @@
     linux_intel_fips: true
     linux_arm_fips: false
   docker:
-    docker_image: cockroachdb/cockroach-unstable
+    docker_image: cockroachdb/cockroach
     docker_arm: true
     docker_arm_experimental: false
     docker_arm_limited_access: false

src/current/_includes/cockroachcloud/cdc/tutorial-privilege-check.md

@@ -0,0 +1 @@
+The `CHANGEFEED` privilege in order to create and manage changefeed jobs. Refer to [Required privileges]({% link {{site.current_cloud_version}}/create-changefeed.md %}#required-privileges) for more details.

src/current/_includes/v19.1/known-limitations/schema-changes-between-prepared-statements.md

@@ -1,42 +1,33 @@
-When the schema of a table targeted by a prepared statement changes before the prepared statement is executed, CockroachDB allows the prepared statement to return results based on the changed table schema, for example:
+When the schema of a table targeted by a prepared statement changes after the prepared statement is created, future executions of the prepared statement could result in an error. For example, adding a column to a table referenced in a prepared statement with a `SELECT *` clause will result in an error:
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> CREATE TABLE users (id INT PRIMARY KEY);
+CREATE TABLE users (id INT PRIMARY KEY);
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> PREPARE prep1 AS SELECT * FROM users;
+PREPARE prep1 AS SELECT * FROM users;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> ALTER TABLE users ADD COLUMN name STRING;
+ALTER TABLE users ADD COLUMN name STRING;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> INSERT INTO users VALUES (1, 'Max Roach');
+INSERT INTO users VALUES (1, 'Max Roach');
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> EXECUTE prep1;
+EXECUTE prep1;
 ~~~
 
 ~~~
-+----+-----------+
-| id |   name    |
-+----+-----------+
-|  1 | Max Roach |
-+----+-----------+
-(1 row)
+ERROR: cached plan must not change result type
+SQLSTATE: 0A000
 ~~~
 
-It's therefore recommended to **not** use `SELECT *` in queries that will be repeated, via prepared statements or otherwise.
-
-Also, a prepared [`INSERT`](insert.html), [`UPSERT`](upsert.html), or [`DELETE`](delete.html) statement acts inconsistently when the schema of the table being written to is changed before the prepared statement is executed:
-
-- If the number of columns has increased, the prepared statement returns an error but nonetheless writes the data.
-- If the number of columns remains the same but the types have changed, the prepared statement writes the data and does not return an error.
+It's therefore recommended to explicitly list result columns instead of using `SELECT *` in prepared statements, when possible.

src/current/_includes/v19.2/known-limitations/schema-changes-between-prepared-statements.md

@@ -1,42 +1,33 @@
-When the schema of a table targeted by a prepared statement changes before the prepared statement is executed, CockroachDB allows the prepared statement to return results based on the changed table schema, for example:
+When the schema of a table targeted by a prepared statement changes after the prepared statement is created, future executions of the prepared statement could result in an error. For example, adding a column to a table referenced in a prepared statement with a `SELECT *` clause will result in an error:
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> CREATE TABLE users (id INT PRIMARY KEY);
+CREATE TABLE users (id INT PRIMARY KEY);
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> PREPARE prep1 AS SELECT * FROM users;
+PREPARE prep1 AS SELECT * FROM users;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> ALTER TABLE users ADD COLUMN name STRING;
+ALTER TABLE users ADD COLUMN name STRING;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> INSERT INTO users VALUES (1, 'Max Roach');
+INSERT INTO users VALUES (1, 'Max Roach');
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> EXECUTE prep1;
+EXECUTE prep1;
 ~~~
 
 ~~~
-+----+-----------+
-| id |   name    |
-+----+-----------+
-|  1 | Max Roach |
-+----+-----------+
-(1 row)
+ERROR: cached plan must not change result type
+SQLSTATE: 0A000
 ~~~
 
-It's therefore recommended to **not** use `SELECT *` in queries that will be repeated, via prepared statements or otherwise.
-
-Also, a prepared [`INSERT`](insert.html), [`UPSERT`](upsert.html), or [`DELETE`](delete.html) statement acts inconsistently when the schema of the table being written to is changed before the prepared statement is executed:
-
-- If the number of columns has increased, the prepared statement returns an error but nonetheless writes the data.
-- If the number of columns remains the same but the types have changed, the prepared statement writes the data and does not return an error.
+It's therefore recommended to explicitly list result columns instead of using `SELECT *` in prepared statements, when possible.

src/current/_includes/v2.1/misc/schema-changes-between-prepared-statements.md

@@ -1,42 +1,33 @@
-When the schema of a table targeted by a prepared statement changes before the prepared statement is executed, CockroachDB allows the prepared statement to return results based on the changed table schema, for example:
+When the schema of a table targeted by a prepared statement changes after the prepared statement is created, future executions of the prepared statement could result in an error. For example, adding a column to a table referenced in a prepared statement with a `SELECT *` clause will result in an error:
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> CREATE TABLE users (id INT PRIMARY KEY);
+CREATE TABLE users (id INT PRIMARY KEY);
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> PREPARE prep1 AS SELECT * FROM users;
+PREPARE prep1 AS SELECT * FROM users;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> ALTER TABLE users ADD COLUMN name STRING;
+ALTER TABLE users ADD COLUMN name STRING;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> INSERT INTO users VALUES (1, 'Max Roach');
+INSERT INTO users VALUES (1, 'Max Roach');
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> EXECUTE prep1;
+EXECUTE prep1;
 ~~~
 
 ~~~
-+----+-----------+
-| id |   name    |
-+----+-----------+
-|  1 | Max Roach |
-+----+-----------+
-(1 row)
+ERROR: cached plan must not change result type
+SQLSTATE: 0A000
 ~~~
 
-It's therefore recommended to **not** use `SELECT *` in queries that will be repeated, via prepared statements or otherwise.
-
-Also, a prepared [`INSERT`](insert.html), [`UPSERT`](upsert.html), or [`DELETE`](delete.html) statement acts inconsistently when the schema of the table being written to is changed before the prepared statement is executed:
-
-- If the number of columns has increased, the prepared statement returns an error but nonetheless writes the data.
-- If the number of columns remains the same but the types have changed, the prepared statement writes the data and does not return an error.
+It's therefore recommended to explicitly list result columns instead of using `SELECT *` in prepared statements, when possible.

src/current/_includes/v20.1/known-limitations/schema-changes-between-prepared-statements.md

@@ -1,42 +1,33 @@
-When the schema of a table targeted by a prepared statement changes before the prepared statement is executed, CockroachDB allows the prepared statement to return results based on the changed table schema, for example:
+When the schema of a table targeted by a prepared statement changes after the prepared statement is created, future executions of the prepared statement could result in an error. For example, adding a column to a table referenced in a prepared statement with a `SELECT *` clause will result in an error:
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> CREATE TABLE users (id INT PRIMARY KEY);
+CREATE TABLE users (id INT PRIMARY KEY);
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> PREPARE prep1 AS SELECT * FROM users;
+PREPARE prep1 AS SELECT * FROM users;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> ALTER TABLE users ADD COLUMN name STRING;
+ALTER TABLE users ADD COLUMN name STRING;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> INSERT INTO users VALUES (1, 'Max Roach');
+INSERT INTO users VALUES (1, 'Max Roach');
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> EXECUTE prep1;
+EXECUTE prep1;
 ~~~
 
 ~~~
-+----+-----------+
-| id |   name    |
-+----+-----------+
-|  1 | Max Roach |
-+----+-----------+
-(1 row)
+ERROR: cached plan must not change result type
+SQLSTATE: 0A000
 ~~~
 
-It's therefore recommended to **not** use `SELECT *` in queries that will be repeated, via prepared statements or otherwise.
-
-Also, a prepared [`INSERT`](insert.html), [`UPSERT`](upsert.html), or [`DELETE`](delete.html) statement acts inconsistently when the schema of the table being written to is changed before the prepared statement is executed:
-
-- If the number of columns has increased, the prepared statement returns an error but nonetheless writes the data.
-- If the number of columns remains the same but the types have changed, the prepared statement writes the data and does not return an error.
+It's therefore recommended to explicitly list result columns instead of using `SELECT *` in prepared statements, when possible.

src/current/_includes/v20.2/known-limitations/schema-changes-between-prepared-statements.md

@@ -1,40 +1,33 @@
-When the schema of a table targeted by a prepared statement changes before the prepared statement is executed, CockroachDB allows the prepared statement to return results based on the changed table schema, for example:
+When the schema of a table targeted by a prepared statement changes after the prepared statement is created, future executions of the prepared statement could result in an error. For example, adding a column to a table referenced in a prepared statement with a `SELECT *` clause will result in an error:
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> CREATE TABLE users (id INT PRIMARY KEY);
+CREATE TABLE users (id INT PRIMARY KEY);
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> PREPARE prep1 AS SELECT * FROM users;
+PREPARE prep1 AS SELECT * FROM users;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> ALTER TABLE users ADD COLUMN name STRING;
+ALTER TABLE users ADD COLUMN name STRING;
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> INSERT INTO users VALUES (1, 'Max Roach');
+INSERT INTO users VALUES (1, 'Max Roach');
 ~~~
 
-{% include copy-clipboard.html %}
+{% include_cached copy-clipboard.html %}
 ~~~ sql
-> EXECUTE prep1;
+EXECUTE prep1;
 ~~~
 
 ~~~
-  id |   name
------+------------
-   1 | Max Roach
-(1 row)
+ERROR: cached plan must not change result type
+SQLSTATE: 0A000
 ~~~
 
-It's therefore recommended to **not** use `SELECT *` in queries that will be repeated, via prepared statements or otherwise.
-
-Also, a prepared [`INSERT`](insert.html), [`UPSERT`](upsert.html), or [`DELETE`](delete.html) statement acts inconsistently when the schema of the table being written to is changed before the prepared statement is executed:
-
-- If the number of columns has increased, the prepared statement returns an error but nonetheless writes the data.
-- If the number of columns remains the same but the types have changed, the prepared statement writes the data and does not return an error.
+It's therefore recommended to explicitly list result columns instead of using `SELECT *` in prepared statements, when possible.

src/current/_includes/v21.1/known-limitations/schema-changes-between-prepared-statements.md

@@ -1,40 +1,33 @@
-When the schema of a table targeted by a prepared statement changes before the prepared statement is executed, CockroachDB allows the prepared statement to return results based on the changed table schema, for example:
+When the schema of a table targeted by a prepared statement changes after the prepared statement is created, future executions of the prepared statement could result in an error. For example, adding a column to a table referenced in a prepared statement with a `SELECT *` clause will result in an error:
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
-> CREATE TABLE users (id INT PRIMARY KEY);
+CREATE TABLE users (id INT PRIMARY KEY);
 ~~~
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
-> PREPARE prep1 AS SELECT * FROM users;
+PREPARE prep1 AS SELECT * FROM users;
 ~~~
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
-> ALTER TABLE users ADD COLUMN name STRING;
+ALTER TABLE users ADD COLUMN name STRING;
 ~~~
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
-> INSERT INTO users VALUES (1, 'Max Roach');
+INSERT INTO users VALUES (1, 'Max Roach');
 ~~~
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
-> EXECUTE prep1;
+EXECUTE prep1;
 ~~~
 
 ~~~
-  id |   name
------+------------
-   1 | Max Roach
-(1 row)
+ERROR: cached plan must not change result type
+SQLSTATE: 0A000
 ~~~
 
-It's therefore recommended to **not** use `SELECT *` in queries that will be repeated, via prepared statements or otherwise.
-
-Also, a prepared [`INSERT`](insert.html), [`UPSERT`](upsert.html), or [`DELETE`](delete.html) statement acts inconsistently when the schema of the table being written to is changed before the prepared statement is executed:
-
-- If the number of columns has increased, the prepared statement returns an error but nonetheless writes the data.
-- If the number of columns remains the same but the types have changed, the prepared statement writes the data and does not return an error.
+It's therefore recommended to explicitly list result columns instead of using `SELECT *` in prepared statements, when possible.