CREATE OR REPLACE for materialized views

Tables and plain views had CREATE OR REPLACE; materialized views did not. Deployment scripts carried an existence check, a DROP and a CREATE, and that sequence is not atomic: between the drop and the create the view does not exist, so inserts arriving in the gap are never transformed into the target table. I asked for CREATE OR REPLACE MATERIALIZED VIEW [db.]name [ON CLUSTER c] [TO t] AS SELECT ... on grounds of consistency and scriptability. An earlier request, #5709, had been closed because its motivation was transactions, which were addressed by giving materialized views ALTER; mine was about scripts.

It took about four months. PR #100539 by il9ue merged on 2026-05-19 and shipped in 26.5. Its description showed the situation was odd: the statement was not unsupported, it was silently misparsed as an ordinary view, because the parser refused to consume MATERIALIZED after OR REPLACE. The machinery underneath already did the right thing: create a temporary view (and inner table when there is no TO), swap atomically with RENAME EXCHANGE, drop the old one.

Things worth knowing from the PR:

• The access check now requires CREATE MATERIALIZED VIEW, not CREATE VIEW, closing a privilege corner.
• Replacing a view that has an inner table creates a new, empty inner table; the old data goes with it.
• POPULATE re-populates on every replace.
• With a TO table, the replace swaps the view and leaves the target alone, which is the safe way to use it.
• OR REPLACE combined with IF NOT EXISTS is a syntax error.

26.4 predates the release and stops at the VIEW keyword:

CREATE OR REPLACE MATERIALIZED VIEW mv TO dst AS SELECT x + 1 AS x FROM src;

Code: 62. DB::Exception: Syntax error: failed at position 32 (VIEW) ...

For the broader picture see materialized views basics and adding a materialized view to an existing table.