Update Row-level TTL docs re: inbound foreign keys

src/current/_includes/v23.2/known-limitations/row-level-ttl-limitations.md

@@ -1,4 +1,5 @@
 - Any queries you run against tables with Row-Level TTL enabled do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query).
+- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372)
 - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes.
     - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index.
     - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.

src/current/_includes/v24.1/known-limitations/row-level-ttl-limitations.md

@@ -1,4 +1,5 @@
 - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query).
+- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372)
 - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes.
     - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index.
     - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.

src/current/_includes/v24.3/known-limitations/row-level-ttl-limitations.md

@@ -1,4 +1,5 @@
 - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query).
+- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372)
 - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes.
     - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index.
     - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.

src/current/_includes/v25.2/known-limitations/row-level-ttl-limitations.md

@@ -1,4 +1,5 @@
 - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query).
+- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372)
 - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes.
     - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index.
     - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.

src/current/_includes/v25.4/known-limitations/row-level-ttl-limitations.md

@@ -1,4 +1,5 @@
 - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query).
+- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372)
 - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes.
     - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index.
     - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.

src/current/_includes/v26.1/known-limitations/row-level-ttl-limitations.md

@@ -1,4 +1,5 @@
 - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query).
+- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372)
 - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes.
     - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index.
     - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.