[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eBigQuery's column-level access control requires read permission for columns protected by policy tags when performing certain write operations that involve reading column data.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eINSERT\u003c/code\u003e statements and data loading operations (from Cloud Storage, local files, or streaming) do not require read permission on the destination table's columns, but users will be unable to read data they have written without read permission.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eDELETE\u003c/code\u003e, \u003ccode\u003eUPDATE\u003c/code\u003e, and \u003ccode\u003eMERGE\u003c/code\u003e statements need read permissions on columns scanned as part of the operation, such as those in a \u003ccode\u003eWHERE\u003c/code\u003e clause or other subquery.\u003c/p\u003e\n"],["\u003cp\u003eCopying data requires read permissions on the source table's columns, but not the destination table's, however once the data is written users must have read permissions to be able to read that data.\u003c/p\u003e\n"],["\u003cp\u003eWhen using BigQuery change data capture, policy tags are checked on the primary key columns.\u003c/p\u003e\n"]]],[],null,["# Impact on writes from column-level access control\n=================================================\n\nThis page explains the impact to writes when you use BigQuery\ncolumn-level access control to restrict access to data at the column level. For\ngeneral information about column-level access control, see [Introduction to\nBigQuery column-level access control](/bigquery/docs/column-level-security-intro).\n\nColumn-level access control requires a user to have read permission for columns that\nare protected by policy tags. Some write operations need to read column data\nbefore actually writing into a column. For those operations,\nBigQuery checks the user's read permission to ensure the user has\naccess to the column. For example, if a user is updating data that includes\nwriting to a protected column, the user must have read permission for the\nprotected column. If the user is inserting a new data row that includes writing\nto a protected column, the user doesn't need read access for the protected\ncolumn. But, the user who writes such a row won't be able to read the newly\nwritten data unless the user has read permission for the protected columns.\n\nThe following sections provide details about different types of write\noperations. The examples in this topic use `customers` tables with the following\nschema:\n\nUsing BigQuery data manipulation language (DML)\n-----------------------------------------------\n\n### Inserting data\n\nFor an `INSERT` statement, BigQuery does not check Fine-Grained\nReader permission on the policy tags on either the scanned columns or the\nupdated columns. This is because an `INSERT` does not require reading any of the\ncolumn data. But, even if you successfully insert values into columns where you\ndon't have read permission, once inserted, the values are protected as expected.\n\n### Deleting, updating, and merging data\n\nFor `DELETE`, `UPDATE`, and `MERGE` statements, BigQuery checks\nfor the Fine-Grained Reader permission on the scanned columns. Columns aren't\nscanned by these statements unless you include a\n[`WHERE` clause](/bigquery/docs/reference/standard-sql/query-syntax#where_clause),\nor some other clause or subquery that requires the query to read data.\n\n### Loading data\n\nWhen loading data (for example, from Cloud Storage or local files) to a\ntable, BigQuery does not check the Fine-Grained Reader\npermission on the columns of the destination table. This is because loading data\ndoes not require reading content from the destination table.\n\nStreaming into BigQuery is similar to `LOAD` and `INSERT`.\nBigQuery lets you stream data into a destination table\ncolumn, even if you don't have the Fine-Grained Reader permission.\n\n### Copying data\n\nFor a copy operation, BigQuery checks whether the user has\nthe Fine-Grained Reader permission on the source table. BigQuery\ndoes not check whether the user has the Fine-Grained Reader permission to the\ncolumns in the destination table. Like `LOAD`, `INSERT`, and streaming,\nonce the copy is complete, you won't be able to read the data that was just\nwritten, unless you have the Fine-Grained Reader permission to the destination\ntable's columns.\n\nDML examples\n------------\n\n### `INSERT`\n\n**Example:** \n\n INSERT INTO customers VALUES('alice', 85, '123-456-7890');\n\n### `UPDATE`\n\n**Example:** \n\n UPDATE customers SET credit_score = 0\n WHERE user_id LIKE 'alice%' AND credit_score \u003c 30\n\n### `DELETE`\n\n**Example:** \n\n DELETE customers WHERE credit_score = 0\n\nLoad examples\n-------------\n\n### Loading from a local file or Cloud Storage\n\n**Example:** \n\n load --source_format=CSV samples.customers \\\n ./customers_data.csv \\\n ./customers_schema.json\n\n### Streaming\n\nNo policy tags are checked when streaming with the legacy `insertAll` streaming API or the\nStorage Write API. For BigQuery [change data capture](/bigquery/docs/change-data-capture), the policy tags are checked on the primary key columns.\n\nCopy examples\n-------------\n\n### Appending data to an existing table\n\n**Example:** \n\n cp -a samples.customers samples.customers_dest\n\n### Saving query results to a destination table\n\n**Example:** \n\n query --use_legacy_sql=false \\\n --max_rows=0 \\\n --destination_table samples.customers_dest \\\n --append_table \"SELECT * FROM samples.customers LIMIT 10;\""]]
