topic Re: Unable to update view comment via SQL/API unless owner, but column comments work (Unity Catalog) in Data Engineering

Unable to update view comment via SQL/API unless owner, but column comments work (Unity Catalog)

shadman140 — Thu, 15 Jan 2026 18:56:47 GMT

I’m working with Databricks Unity Catalog and observing an inconsistent permission behavior for views.

Scenario

A view exists that was created by another user
I have sufficient privileges on the catalog/schema/view (SELECT, MODIFY, ALL PRIVILEGES)
I can:
- Query the view
- Add column comments for view successfully using SQL editor in databricks UI and /statements api end point with COMMENT ON COLUMN query
- Update the view comment via Databricks UI
But I cannot update the view-level comment via SQL editor in databricks UI or API

Question

Why Views is bound by this owner condition while table works with MODIFY permission only?
While documentation says, "Comment on column" will only work for owners but I am able to use it even when I don't own the view?

Re: Unable to update view comment via SQL/API unless owner, but column comments work (Unity Catalog)

stbjelcevic — Thu, 15 Jan 2026 23:29:02 GMT

Interesting, for UC, COMMENT ON COLUMN requires MODIFY on a table, and OWNER on a view. If multiple people need to maintain a view, the recommended pattern is to make a group the owner and grant that group the required access to source data. Why is it designed like that: to reduce the risk of privilege escalation via view edits. (FYI, I didn't make these decisions, this is just what I'm able to find).

Note that granting ALL PRIVILEGES on a view doesn’t give you OWNER or even MANAGE.

Is it possible the view is owned by a group that you belong to? You can use the following to see who owns the view:
DESCRIBE EXTENDED catalog.schema.view_name; -- Owner is shown in the Detailed Table Information section.

Re: Unable to update view comment via SQL/API unless owner, but column comments work (Unity Catalog)

johnkw — Wed, 18 Feb 2026 23:23:26 GMT

SQL to update View comments appeared to work

%sql
COMMENT ON VIEW <catalog>.<schema>.<view> IS
'DESCRIPTION:
Test Comments.
| | |
| -------------- | ------------------------------------- |
|**Update Frequency:**|Weekly |
|**Data Engineer:**|Jane Doe |
|**Subject Matter Contact:**|Joe User |
'

Hi @shadman140, This is expected behavior based on how Un...

SteveOstrowski — Mon, 09 Mar 2026 00:54:40 GMT

Hi @shadman140,

This is expected behavior based on how Unity Catalog privileges are defined for views versus tables, though the inconsistency you noticed is understandable.

THE SHORT ANSWER

COMMENT ON for a view (at the view level) requires you to be the view OWNER. This is different from tables, where MODIFY privilege is sufficient.

WHY VIEWS AND TABLES DIFFER

In Unity Catalog, the set of grantable privileges for views is more restricted than for tables. Specifically:

- Tables support: ALL PRIVILEGES, APPLY TAG, MANAGE, MODIFY, SELECT
- Views support: ALL PRIVILEGES, APPLY TAG, MANAGE, SELECT

Notice that views do not have a MODIFY privilege at all. The COMMENT ON statement for tables requires MODIFY (or ownership). Since views lack MODIFY, the only path to COMMENT ON a view is through ownership.

This is documented here:
https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-comment.html

The privilege requirements from that page:
- COMMENT ON TABLE: requires MODIFY privilege on the table (or ownership)
- COMMENT ON a view: requires being the OWNER of the view

ABOUT COLUMN COMMENTS ON VIEWS

You mentioned that column-level comments work on views even without ownership. The documentation states that commenting on a column of a view also requires ownership. If you are able to do this without being the owner, it may be that your ALL PRIVILEGES grant is being interpreted in a way that permits column-level comments but not view-level comments. This could also vary depending on the method you are using (UI vs SQL editor vs /api/2.0/sql/statements endpoint), since the UI may go through a different code path.

WORKAROUND OPTIONS

1. Transfer ownership to a group: If multiple users need to manage view comments, you can transfer the view ownership to a shared group using:

 ALTER VIEW catalog.schema.view_name SET OWNER TO group_name;

 Any member of that group will then be treated as an owner. The person executing this must either be a member of the target group or a metastore admin.
 https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-alter-view.html

2. Use the UI: You mentioned that updating view comments through the Databricks UI works. If programmatic access is not strictly required, this remains a viable path.

3. Run COMMENT ON as the view owner: If you have a service principal or automation account that owns the views, route the comment updates through that identity.

WHY THIS DESIGN EXISTS

Views in Unity Catalog are treated more like derived/logical objects rather than physical storage objects. The MODIFY privilege on tables covers data mutation (INSERT, UPDATE, DELETE) and metadata changes like comments. Since views don't hold data directly, MODIFY was not included in the view privilege model. Comment management on views falls under the broader "object definition management" category, which is reserved for owners (or those with MANAGE for certain operations, though MANAGE does not currently cover COMMENT ON).

SUMMARY

- COMMENT ON VIEW requires ownership (by design, since views lack MODIFY)
- COMMENT ON TABLE requires MODIFY (or ownership)
- Column comments on views should also require ownership per documentation
- Transferring view ownership to a shared group is the recommended approach if multiple users need to manage view metadata

Documentation references:
- COMMENT ON: https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-comment.html
- Unity Catalog privileges: https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html
- ALTER VIEW: https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-alter-view.html

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

If this answer resolves your question, could you mark it as "Accept as Solution"? That helps other users quickly find the correct fix.