docs: describe materialized-view refresh as a full rebuild

Main now rebuilds a materialized view completely on every refresh
(#4373): there is no incremental mode, no `full` argument and no
stable-row-ID requirement on the source. The example ran against the
SDK built from this branch (0.40.0b13) failed, because a refresh after
adding Bea writes both matching rows, not one.

The example now creates its source with the default options and expects
two rows written by the refresh, and its generated snippet is
regenerated. Separate tests cover `with_no_data` (one matching row on
the first refresh) and refreshing to an earlier source version. The
refresh page explains the full rebuild and keeps the #incremental and
#stable-row-ids anchors for the sections that replace them. Its version
note now says what the published 0.39.0 does differently, as observed
with that release.

The management, table, database, limits, architecture and data-types
pages no longer say a view's source needs stable row ids, and the
feature-engineering and tutorial summaries no longer call refreshes
incremental.
This commit is contained in:
Brendan Clement
2026-10-06 20:44:06 -07:00
parent 2e5ca5f8c5
commit 622e6078c1
11 changed files with 61 additions and 84 deletions
-3
View File
@@ -137,9 +137,6 @@ Row metadata, available only when named — so it stays out of `SELECT *`:
their validity bitmap is reused internally as a selection vector. Do not read a
null there as meaningful.
`_rowid` is what [materialized views](/management/materialized-view) depend on,
which is why a source table needs stable row ids enabled at creation.
## Casting {#casting}
```sql