[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# Parameterized secure views overview\n\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n|\n|\n| For information about access to this\n| release, see the\n| [access request page](https://docs.google.com/forms/d/16wliam2vok6sdBjYwJIgWV4hw7MW9x5iQ29UwPAKqB0/viewform).\n\nThis document describes parameterized secure views in AlloyDB for PostgreSQL, which\ngive application data security\nand row access control while supporting SQL. These views support *data value\nextraction* ---the process of retrieving specific data pieces from\ncolumns---and they help protect against\n[prompt injection attacks](https://en.wikipedia.org/wiki/Prompt_injection).\nParameterized secure views help ensure that end users can view only the data that\nthey are supposed to access.\n\nParameterized views are an extension of\n[PostgreSQL views](https://www.postgresql.org/docs/current/tutorial-views.html),\nwhich let you use application-specific named view parameters in view definitions.\nThis capability provides an interface that takes a query and values for the named\nparameters. The views execute the query with those values, which\nare used throughout the execution of that query.\n\nThe following is an example of a parameterized secure view: \n\n CREATE VIEW secure_checked_items WITH (security_barrier) AS\n SELECT bag_id, timestamp, location\n FROM checked_items t\n WHERE customer_id = $@app_end_userid;\n\nYou can query the views using the `execute_parameterized_query` stored procedure,\nor by running the `EXECUTE .. WITH VIEW PARAMETERS` statement.\n\n### Use cases\n\nParameterized secure views are well suited for data security administration at\nthe database level against ad hoc queries from untrusted sources, such as\nqueries translated from natural language queries. For example, consider an\napplication whose database tracks the checked-in luggage of traveling customers.\nThese customers can issue queries to the application. For example, a customer\nwith the application user ID 12345 can enter a query into the application like,\n\"Where is my bag?\"\n\nYou can use parameterized secure views to apply the following requirements to\nhow AlloyDB executes this query:\n\n- The query can read only the database objects and columns that you listed in your database parameterized secure views.\n- The query can read only the database rows that are associated with the user who submitted the query. The returned rows have a data relationship with the user's table row whose ID column value is `12345`.\n\nFor more information about configuring security and access control, see\n[Secure and control access to application data using parameterized secure views](/alloydb/docs/manage-application-data-security-parameterized-secure-views#configure).\n\nParameterized secure views help to mitigate security risks that occur when end\nusers are allowed to run untrusted queries, like natural language queries, on\nthe database table. Security risks include the following:\n\n- Users can submit prompt injection attacks and try to manipulate the underlying model to reveal all the data that the application has access to.\n- The LLM might generate SQL queries that are broader in scope than is appropriate for data security reasons. This security risk can expose sensitive data in response to even well-intentioned user queries.\n\nUsing parameterized secure views, you can define the tables and columns that\nuntrusted queries can pull data from. These views let you restrict the range of rows\navailable to an individual application user. These restrictions also let you tightly\ncontrol the data that application users can view through natural language\nqueries, regardless of how users phrase those queries.\n\n### Security mechanism\n\nParameterized secure views give application developers data security\nand row access control using the following methods:\n\n- Views created using the [`WITH (security barrier)`](https://www.postgresql.org/docs/current/rules-privileges.html) option provide row-level security by preventing maliciously-chosen functions and operators from being passed values from rows until after the view has done its work. For more information about the `WITH (security barrier)` clause, see [Rules and Privileges](https://www.postgresql.org/docs/current/rules-privileges.html).\n- Parameterization using named view parameters allows a restricted view of the database parameterized by values provided by the application based on application-level security such as end user authentication.\n- Enforcement of additional restrictions on queries accessing parameterized views that prevents attacks against escaping the checks in the views based on the given parameter values. For more information, see [Enforced restrictions on queries](/alloydb/docs/manage-application-data-security-parameterized-secure-views#restrictions).\n\nLimitations\n-----------\n\n- If a parameterized view is referenced in a user-defined function that is\n called using any of the [APIs used in parameterized secure views](/alloydb/docs/manage-application-data-security-parameterized-secure-views#query-parameterized-secure-view),\n an error occurs. You must directly reference the parameterized view\n in the parent query.\n\n- You must enable the parameterized view flag separately on every instance of\n AlloyDB. Parameterized view objects created on the primary\n instance are propagated to read-only replicas and cross-region replicas.\n However, the `parameterized_views.enabled` flag setting isn't replicated\n automatically and must be replicated manually on each instance. For more\n information, see [Before you begin](/alloydb/docs/manage-application-data-security-parameterized-secure-views#before-you-begin). You can't query parameterized views on the replica before you enable\n the `parameterized_views.enabled` flag on each replica instance. This\n limitation doesn't apply to the standby instance.\n\nWhat's next\n-----------\n\n- [Manage application data security using parameterized secure views](/alloydb/docs/manage-application-data-security-parameterized-secure-views).\n- [Secure and control access to application data using parameterized secure views](/alloydb/docs/secure-app-data-parameterized-secure-views)."]]