<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Tags Field Doesn't propagate in Delta Share in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/150170#M53285</link>
    <description>&lt;P&gt;Hi &lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/178678"&gt;@souravroy1990&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;You are correct that Unity Catalog tags (set via ALTER TABLE SET TAGS or ALTER TABLE ALTER COLUMN SET TAGS) are not propagated to recipients through Delta Sharing. Tags are treated as Unity Catalog governance metadata that lives in the provider's metastore and is not included in the share payload. What IS included in Databricks-to-Databricks shares (as of mid-2024) are table comments, column comments, and primary key constraints.&lt;/P&gt;
&lt;P&gt;Here are a few approaches to get tag-like information to your share recipients:&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;OPTION 1: MATERIALIZE TAG DATA INTO A SHARED DELTA TABLE&lt;/P&gt;
&lt;P&gt;This is the most robust approach. You can query the information_schema views for tags in your provider catalog and write the results into a regular Delta table, then include that Delta table in your share.&lt;/P&gt;
&lt;P&gt;On the provider side, create and populate the tag table:&lt;/P&gt;
&lt;P&gt;CREATE TABLE my_catalog.my_schema.shared_tag_metadata AS&lt;BR /&gt;SELECT * FROM my_catalog.information_schema.column_tags&lt;BR /&gt;WHERE table_name IN ('table1', 'table2');&lt;/P&gt;
&lt;P&gt;You can also combine table-level and column-level tags:&lt;/P&gt;
&lt;P&gt;CREATE OR REPLACE TABLE my_catalog.my_schema.shared_tag_metadata AS&lt;BR /&gt;SELECT&lt;BR /&gt;catalog_name, schema_name, table_name,&lt;BR /&gt;NULL AS column_name,&lt;BR /&gt;tag_name, tag_value,&lt;BR /&gt;'TABLE' AS tag_level&lt;BR /&gt;FROM my_catalog.information_schema.table_tags&lt;BR /&gt;WHERE table_name IN ('table1', 'table2')&lt;BR /&gt;UNION ALL&lt;BR /&gt;SELECT&lt;BR /&gt;catalog_name, schema_name, table_name,&lt;BR /&gt;column_name,&lt;BR /&gt;tag_name, tag_value,&lt;BR /&gt;'COLUMN' AS tag_level&lt;BR /&gt;FROM my_catalog.information_schema.column_tags&lt;BR /&gt;WHERE table_name IN ('table1', 'table2');&lt;/P&gt;
&lt;P&gt;Then add it to your share:&lt;/P&gt;
&lt;P&gt;ALTER SHARE my_share ADD TABLE my_catalog.my_schema.shared_tag_metadata;&lt;/P&gt;
&lt;P&gt;To keep it current, schedule a job that periodically refreshes this table (e.g., with CREATE OR REPLACE TABLE or a MERGE). Recipients can then join this metadata table with the shared data tables on catalog_name, schema_name, table_name, and column_name to look up the tags.&lt;/P&gt;
&lt;P&gt;Note: you cannot directly share information_schema views through Delta Sharing because shareable views must be defined on Delta tables, other shareable views, or materialized views. That is why materializing into a Delta table is necessary.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;OPTION 2: STRUCTURED JSON IN COLUMN COMMENTS&lt;/P&gt;
&lt;P&gt;As you mentioned, column comments do propagate through Delta Sharing. If you want to keep both the description and tag metadata in the comment field, you can use a structured JSON format to make parsing straightforward for recipients:&lt;/P&gt;
&lt;P&gt;ALTER TABLE my_catalog.my_schema.my_table&lt;BR /&gt;ALTER COLUMN my_column&lt;BR /&gt;COMMENT '{"description": "Customer unique identifier", "tags": {"pii": "true", "classification": "confidential"}}';&lt;/P&gt;
&lt;P&gt;Recipients can then parse the JSON comment on their side:&lt;/P&gt;
&lt;P&gt;SELECT&lt;BR /&gt;column_name,&lt;BR /&gt;get_json_object(comment, '$.description') AS description,&lt;BR /&gt;get_json_object(comment, '$.tags.pii') AS pii_tag,&lt;BR /&gt;get_json_object(comment, '$.tags.classification') AS classification_tag&lt;BR /&gt;FROM recipient_catalog.information_schema.columns&lt;BR /&gt;WHERE table_name = 'my_table';&lt;/P&gt;
&lt;P&gt;This keeps everything in one field but with a clear, parseable structure. The downside is that it requires coordination with your recipients on the JSON schema.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;OPTION 3: SHARE A VIEW THAT EMBEDS TAGS AS COLUMNS&lt;/P&gt;
&lt;P&gt;If your use case is focused on a small number of well-known tags, you could create a view that adds tag values as extra columns, then share the view:&lt;/P&gt;
&lt;P&gt;CREATE VIEW my_catalog.my_schema.my_table_with_tags AS&lt;BR /&gt;SELECT&lt;BR /&gt;*,&lt;BR /&gt;'true' AS tag_pii,&lt;BR /&gt;'confidential' AS tag_classification&lt;BR /&gt;FROM my_catalog.my_schema.my_table;&lt;/P&gt;
&lt;P&gt;ALTER SHARE my_share ADD VIEW my_catalog.my_schema.my_table_with_tags;&lt;/P&gt;
&lt;P&gt;This is simple but does not scale well if you have many tags or if tags change frequently.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;RECOMMENDATION&lt;/P&gt;
&lt;P&gt;Option 1 (materialized tag metadata table) is the most flexible and scalable approach. It keeps your actual column comments free for descriptions, gives recipients a clean relational way to look up tags, and can be automated with a scheduled job. This is similar to what &lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/202980"&gt;@pradeep_singh&lt;/a&gt; suggested, and the key detail is that you need to materialize the information_schema data into a Delta table first since information_schema views themselves cannot be shared directly.&lt;/P&gt;
&lt;P&gt;For reference:&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/data-sharing/create-share.html" target="_blank"&gt;https://docs.databricks.com/en/data-sharing/create-share.html&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/data-governance/unity-catalog/tags.html" target="_blank"&gt;https://docs.databricks.com/en/data-governance/unity-catalog/tags.html&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/sql/language-manual/information-schema/column_tags.html" target="_blank"&gt;https://docs.databricks.com/en/sql/language-manual/information-schema/column_tags.html&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/sql/language-manual/information-schema/table_tags.html" target="_blank"&gt;https://docs.databricks.com/en/sql/language-manual/information-schema/table_tags.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;* 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.&lt;/P&gt;</description>
    <pubDate>Sun, 08 Mar 2026 07:23:31 GMT</pubDate>
    <dc:creator>SteveOstrowski</dc:creator>
    <dc:date>2026-03-08T07:23:31Z</dc:date>
    <item>
      <title>Tags Field Doesn't propagate in Delta Share</title>
      <link>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/145346#M52485</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;My current work requires it to add tags in Databricks tables &amp;amp; views. I see that there is a tag column associated to tables and views to which we can set the TAG using &lt;STRONG&gt;SET TAG&lt;/STRONG&gt; command.&lt;/P&gt;&lt;P&gt;My requirement is that once we are creating delta shares out of these tables and views the tags should be visible to the consumers. Currently Databricks doesn’t propagate this information in delta share and as I’m exploring this the reason for not propagating this is this is considered as metadata.&lt;/P&gt;&lt;P&gt;My question is, if we have a requirement of propagating the column level tags to the views associated to a delta share what is the mechanism in Databricks which would enable this?&lt;/P&gt;&lt;P&gt;Databricks community suggests using column comments field which propagates in share, but we are using the comment field for column description. Since this is a string field it would be difficult for the receiver to parse this field to exact 2 different information (column description and metadata), so we want to avoid using comment for metadata.&lt;/P&gt;&lt;P&gt;So is there any alternative to share tags in the delta share to the recipient of the share?&lt;/P&gt;</description>
      <pubDate>Tue, 27 Jan 2026 06:37:37 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/145346#M52485</guid>
      <dc:creator>souravroy1990</dc:creator>
      <dc:date>2026-01-27T06:37:37Z</dc:date>
    </item>
    <item>
      <title>Re: Tags Field Doesn't propagate in Delta Share</title>
      <link>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/146361#M52628</link>
      <description>&lt;P&gt;You can use comments for it. Its easy to parse this field&lt;/P&gt;&lt;DIV&gt;&lt;DIV&gt;&lt;SPAN&gt;COMMENT&lt;/SPAN&gt; &lt;SPAN&gt;'{"des": "key", "meta": {"UPI": "true"}}'&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
      <pubDate>Sat, 31 Jan 2026 17:04:21 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/146361#M52628</guid>
      <dc:creator>balajij8</dc:creator>
      <dc:date>2026-01-31T17:04:21Z</dc:date>
    </item>
    <item>
      <title>Re: Tags Field Doesn't propagate in Delta Share</title>
      <link>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/146388#M52635</link>
      <description>&lt;P&gt;The catalog that you are sharing should have information_schema.table_tags and&amp;nbsp;information_schema.column_tags tables . You can share these two tables as well if you are not sharing it today .&amp;nbsp;&lt;/P&gt;&lt;P&gt;You can then ask your share recipient to join these tables to the tables you have shared to get details on the tags for each table and column . You can also get creative with using the tags from table_tags and column_tags to define your comments value when creating share and see if that help propogate the tags.&lt;/P&gt;</description>
      <pubDate>Sun, 01 Feb 2026 04:41:57 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/146388#M52635</guid>
      <dc:creator>pradeep_singh</dc:creator>
      <dc:date>2026-02-01T04:41:57Z</dc:date>
    </item>
    <item>
      <title>Re: Tags Field Doesn't propagate in Delta Share</title>
      <link>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/150170#M53285</link>
      <description>&lt;P&gt;Hi &lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/178678"&gt;@souravroy1990&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;You are correct that Unity Catalog tags (set via ALTER TABLE SET TAGS or ALTER TABLE ALTER COLUMN SET TAGS) are not propagated to recipients through Delta Sharing. Tags are treated as Unity Catalog governance metadata that lives in the provider's metastore and is not included in the share payload. What IS included in Databricks-to-Databricks shares (as of mid-2024) are table comments, column comments, and primary key constraints.&lt;/P&gt;
&lt;P&gt;Here are a few approaches to get tag-like information to your share recipients:&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;OPTION 1: MATERIALIZE TAG DATA INTO A SHARED DELTA TABLE&lt;/P&gt;
&lt;P&gt;This is the most robust approach. You can query the information_schema views for tags in your provider catalog and write the results into a regular Delta table, then include that Delta table in your share.&lt;/P&gt;
&lt;P&gt;On the provider side, create and populate the tag table:&lt;/P&gt;
&lt;P&gt;CREATE TABLE my_catalog.my_schema.shared_tag_metadata AS&lt;BR /&gt;SELECT * FROM my_catalog.information_schema.column_tags&lt;BR /&gt;WHERE table_name IN ('table1', 'table2');&lt;/P&gt;
&lt;P&gt;You can also combine table-level and column-level tags:&lt;/P&gt;
&lt;P&gt;CREATE OR REPLACE TABLE my_catalog.my_schema.shared_tag_metadata AS&lt;BR /&gt;SELECT&lt;BR /&gt;catalog_name, schema_name, table_name,&lt;BR /&gt;NULL AS column_name,&lt;BR /&gt;tag_name, tag_value,&lt;BR /&gt;'TABLE' AS tag_level&lt;BR /&gt;FROM my_catalog.information_schema.table_tags&lt;BR /&gt;WHERE table_name IN ('table1', 'table2')&lt;BR /&gt;UNION ALL&lt;BR /&gt;SELECT&lt;BR /&gt;catalog_name, schema_name, table_name,&lt;BR /&gt;column_name,&lt;BR /&gt;tag_name, tag_value,&lt;BR /&gt;'COLUMN' AS tag_level&lt;BR /&gt;FROM my_catalog.information_schema.column_tags&lt;BR /&gt;WHERE table_name IN ('table1', 'table2');&lt;/P&gt;
&lt;P&gt;Then add it to your share:&lt;/P&gt;
&lt;P&gt;ALTER SHARE my_share ADD TABLE my_catalog.my_schema.shared_tag_metadata;&lt;/P&gt;
&lt;P&gt;To keep it current, schedule a job that periodically refreshes this table (e.g., with CREATE OR REPLACE TABLE or a MERGE). Recipients can then join this metadata table with the shared data tables on catalog_name, schema_name, table_name, and column_name to look up the tags.&lt;/P&gt;
&lt;P&gt;Note: you cannot directly share information_schema views through Delta Sharing because shareable views must be defined on Delta tables, other shareable views, or materialized views. That is why materializing into a Delta table is necessary.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;OPTION 2: STRUCTURED JSON IN COLUMN COMMENTS&lt;/P&gt;
&lt;P&gt;As you mentioned, column comments do propagate through Delta Sharing. If you want to keep both the description and tag metadata in the comment field, you can use a structured JSON format to make parsing straightforward for recipients:&lt;/P&gt;
&lt;P&gt;ALTER TABLE my_catalog.my_schema.my_table&lt;BR /&gt;ALTER COLUMN my_column&lt;BR /&gt;COMMENT '{"description": "Customer unique identifier", "tags": {"pii": "true", "classification": "confidential"}}';&lt;/P&gt;
&lt;P&gt;Recipients can then parse the JSON comment on their side:&lt;/P&gt;
&lt;P&gt;SELECT&lt;BR /&gt;column_name,&lt;BR /&gt;get_json_object(comment, '$.description') AS description,&lt;BR /&gt;get_json_object(comment, '$.tags.pii') AS pii_tag,&lt;BR /&gt;get_json_object(comment, '$.tags.classification') AS classification_tag&lt;BR /&gt;FROM recipient_catalog.information_schema.columns&lt;BR /&gt;WHERE table_name = 'my_table';&lt;/P&gt;
&lt;P&gt;This keeps everything in one field but with a clear, parseable structure. The downside is that it requires coordination with your recipients on the JSON schema.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;OPTION 3: SHARE A VIEW THAT EMBEDS TAGS AS COLUMNS&lt;/P&gt;
&lt;P&gt;If your use case is focused on a small number of well-known tags, you could create a view that adds tag values as extra columns, then share the view:&lt;/P&gt;
&lt;P&gt;CREATE VIEW my_catalog.my_schema.my_table_with_tags AS&lt;BR /&gt;SELECT&lt;BR /&gt;*,&lt;BR /&gt;'true' AS tag_pii,&lt;BR /&gt;'confidential' AS tag_classification&lt;BR /&gt;FROM my_catalog.my_schema.my_table;&lt;/P&gt;
&lt;P&gt;ALTER SHARE my_share ADD VIEW my_catalog.my_schema.my_table_with_tags;&lt;/P&gt;
&lt;P&gt;This is simple but does not scale well if you have many tags or if tags change frequently.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;RECOMMENDATION&lt;/P&gt;
&lt;P&gt;Option 1 (materialized tag metadata table) is the most flexible and scalable approach. It keeps your actual column comments free for descriptions, gives recipients a clean relational way to look up tags, and can be automated with a scheduled job. This is similar to what &lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/202980"&gt;@pradeep_singh&lt;/a&gt; suggested, and the key detail is that you need to materialize the information_schema data into a Delta table first since information_schema views themselves cannot be shared directly.&lt;/P&gt;
&lt;P&gt;For reference:&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/data-sharing/create-share.html" target="_blank"&gt;https://docs.databricks.com/en/data-sharing/create-share.html&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/data-governance/unity-catalog/tags.html" target="_blank"&gt;https://docs.databricks.com/en/data-governance/unity-catalog/tags.html&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/sql/language-manual/information-schema/column_tags.html" target="_blank"&gt;https://docs.databricks.com/en/sql/language-manual/information-schema/column_tags.html&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/en/sql/language-manual/information-schema/table_tags.html" target="_blank"&gt;https://docs.databricks.com/en/sql/language-manual/information-schema/table_tags.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;* 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.&lt;/P&gt;</description>
      <pubDate>Sun, 08 Mar 2026 07:23:31 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/tags-field-doesn-t-propagate-in-delta-share/m-p/150170#M53285</guid>
      <dc:creator>SteveOstrowski</dc:creator>
      <dc:date>2026-03-08T07:23:31Z</dc:date>
    </item>
  </channel>
</rss>

