Upcoming change to CREATE OR REPLACE VIEW metadata preservation

Written by Dinesh Pawar

Last published at: October 5th, 2026

Overview

Starting on Dec 2 2026, CREATE OR REPLACE VIEW will update a view in-place instead of dropping and re-creating it. Grants, tags and comments are preserved by default with two caveats:

  • As views execute with view owner’s permissions, grants are not preserved if a non-owner modifies the view definition via CREATE OR REPLACE VIEW.
  • You must first remove Governed tags (AWS | Azure | GCP) on a view column before dropping the column via CREATE OR REPLACE VIEW. Otherwise, the statement will fail with a CANNOT_DROP_TAGGED_COLUMN error. 

 

After this change, workflows that replace views may retain permissions that were previously dropped, or fail when removing view columns with governed tags.

 

Where does this apply

This change applies when you run CREATE OR REPLACE VIEW on:

  • Classic all-purpose or jobs compute running Databricks Runtime 19 or above
  • Databricks SQL warehouses (serverless, pro, or classic)
  • Serverless compute for notebooks and jobs
  • Spark Declarative Pipelines (serverless or classic)

 

How to know if a view or workflow is exposed to the change

A. The workflow depends on metadata being cleared

  • The view has grants applied directly on the view, rather than inherited from the schema or catalog.
  • The pipeline relies on COR VIEW removing those grants, tags or comments.
  • Escape hatch: Add NOCOPY *, which drops grants, comments and tags (except governed tags).
CREATE OR REPLACE VIEW main.sales.revenue_daily 
NOCOPY * 
AS SELECT date, SUM(amount) AS revenue
FROM main.sales.transactions
GROUP BY date;

B. The workflow removes or renames governed-tagged columns

  • A governed tag is set on a view column, and COR VIEW statement removes or renames that column
  • Workaround: Unset the governed tag first, then run COR VIEW
UNSET TAG ON COLUMN <catalog>.<schema>.<view>.<column> <tag_key>;
CREATE OR REPLACE VIEW <catalog>.<schema>.<view> ...

 

Note

There is no escape hatch for dropping a governed-tagged column. This is consistent with ALTER VIEW today, and a security requirement to support ABAC policies on VIEW.

 

 

What you can do now

1. Identify affected views and workloads

Use the diagnostic notebook to find views with directly assigned grants or columns carrying governed tags.

 

2. Adopt the workarounds outlined above 

Adopt the NOCOPY *  syntax to drop grants, comments and tags on view replacement, and remove any governed tags before removing a tagged view column via CREATE OR REPLACE VIEW.

 

Appendix

Why do we drop grants when a non-owner modifies the view definition via CREATE OR REPLACE (COR)?

If COR VIEW preserves grants on views, users may access data through the new owner's permissions via grants issued under the previous owner:

Step Example
1

Alice creates and owns view_sales that reads from table_sales. Bob is granted SELECT on view_sales .

CREATE VIEW view_sales AS SELECT * FROM table_sales 
2

Carol has MANAGE on view_sales and runs.

CREATE OR REPLACE VIEW view_sales AS SELECT * FROM carols_secrets 
3

Carol is now the owner of view_sales, and Bob keeps SELECT on view_sales since grants on views are preserved.
4 Bob queries view_sales and sees carols_secrets, but Carol never granted SELECT to Bob on view_sales.

When is it safe to preserve grants on views?

Retaining grants on COR VIEW is safe only if ownership or view definition remains unchanged. If view definition is modified, it is only safe to retain grants when ownership remains unchanged: 

COR VIEW run by Ownership preserved? Grants preserved ? Safe?
Owner Yes No Safe: Grants dropped (current behaviour) 
Yes

Safe - grants stay under the same owner 

(same trust boundary as ALTER VIEW AS today)
Non-owner No No Safe: Grants dropped (current behaviour) 
Yes Not safe: Grants not issued under the new owner are preserved - security escalation vector (see below)

 

Why should we block users from dropping a governed-tagged column via COR VIEW

Removing a governed tag requires APPLY TAG on the view + MANAGE on the tag. whereas COR VIEW requires ownership or MANAGE on the view. A user without permissions to drop a governed tag can do so via COR VIEW: 

Step Example
1

Admin applies governed tag pii to the ssn column of sales_view.

CREATE VIEW sales_view AS SELECT date, amount, ssn FROM sales_table
2

View owner or user with MANAGE runs COR VIEW to remove ssn column and the pii tag.

CREATE OR REPLACE VIEW sales_view AS SELECT date, amount FROM sales_table

Current behavior:  Drops ssn with pii tag successfully.

New behavior: Fails with CANNOT_DROP_TAGGED_COLUMN error; must UNSET TAG first
3

COR VIEW user can restore ssn column without the governed tag, thereby dropping the tag policy.

CREATE OR REPLACE VIEW sales_view AS SELECT date, amount, ssn FROM sales_table