{"Entry":{"collection":"relopts","key":"view-security-invoker","name":"security_invoker","aliases":["view.security_invoker"],"metadata":{"aliases":["view.security_invoker"],"category":"View options","content_hash":"9097e5b623fc56db5d923319ad695ed637f0a6d21405982125ba1090911122a5","imported_at":"2026-09-30T17:44:22.414751+08:00","name":"security_invoker","name_zh":"security_invoker","slug":"view-security-invoker","summary":"This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner. See the notes below for full details."}},"Definition":{"Collection":"relopts","Key":"view-security-invoker","SourceDatabase":"center","Version":"18","SourceTable":"relopt","SourceKey":"view-security-invoker","SourceRevision":"eb6c2292fdf28e1b4635ab478eec3919411cdf4a6c07553387870e26201f3744","Facts":{"description":["This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner. See the notes below for full details."],"facts":[{"label":"Applies to","value":"View options"},{"label":"Value type","value":"boolean"}],"related":[{"label":"CREATE VIEW","url":"/wiki/sql/create-view/?v=18"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"Local English manual 18.6","revision":"eb6c2292fdf28e1b4635ab478eec3919411cdf4a6c07553387870e26201f3744"},"sections":[{"paragraphs":["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."],"title":"View options"},{"paragraphs":["If the view has the security_invoker property set to true , access to the underlying base relations is determined by the permissions of the user executing the query, rather than the view owner. Thus, the user of a security invoker view must have the relevant permissions on the view and its underlying base relations.","If any of the underlying base relations is a security invoker view, it will be treated as if it had been accessed directly from the original query. Thus, a security invoker view will always check its underlying base relations using the permissions of the current user, even if it is accessed from a view without the security_invoker property.","If any of the underlying base relations has row-level security enabled, then by default, the row-level security policies of the view owner are applied, and access to any additional relations referred to by those policies is determined by the permissions of the view owner. However, if the view has security_invoker set to true , then the policies and permissions of the invoking user are used instead, as if the base relations had been referenced directly from the query using the view.","Functions called in the view are treated the same as if they had been called directly from the query using the view. Therefore, the user of a view must have permissions to call all functions used by the view. Functions in the view are executed with the privileges of the user executing the query or the function owner, depending on whether the functions are defined as SECURITY INVOKER or SECURITY DEFINER . Thus, for example, calling CURRENT_USER directly in a view will always return the invoking user, not the view owner. This is not affected by the view's security_invoker setting, and so a view with security_invoker set to false is not equivalent to a SECURITY DEFINER function and those concepts should not be confused.","Note that the user performing the insert, update or delete on the view must have the corresponding insert, update or delete privilege on the view. In addition, by default, the view's owner must have the relevant privileges on the underlying base relations, whereas the user performing the update does not need any permissions on the underlying base relations (see Section 39.5 ). However, if the view has security_invoker set to true , the user performing the update, rather than the view owner, must have the relevant privileges on the underlying base relations."],"title":"Security semantics"}],"signature":"WITH (security_invoker = value)","sources":[{"label":"PostgreSQL 18 English manual","path":"sql-createview.html","sha256":"0c11551250a39c2136437e8cded6bcb5bb8d324fa60b9b2e86b2276ad60ee599","url":"/docs/18/sql-createview.html"}]},"ManualEvidence":{"release":{"channel":"stable","label":"18.6","major":"18","ref":"Local English manual 18.6","revision":"eb6c2292fdf28e1b4635ab478eec3919411cdf4a6c07553387870e26201f3744"},"sources":[{"label":"PostgreSQL 18 English manual","path":"sql-createview.html","sha256":"0c11551250a39c2136437e8cded6bcb5bb8d324fa60b9b2e86b2276ad60ee599","url":"/docs/18/sql-createview.html"}]},"MeasuredEvidence":{}},"Text":{"Collection":"relopts","Key":"view-security-invoker","SourceDatabase":"center","Version":"18","Locale":"en","Title":"security_invoker","Summary":"This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner. See the notes below for full details.","BodyHTML":"\u003cp\u003eThis option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner. See the notes below for full details.\u003c/p\u003e","SourceRevision":"eb6c2292fdf28e1b4635ab478eec3919411cdf4a6c07553387870e26201f3744","ContentHash":"334f4b63d612e1d29d7b03283c0c94b4b26f27057f51912cfb00e23ccbe521e3","Payload":{"description":["This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner. See the notes below for full details."],"related":[{"label":"CREATE VIEW","url":"/wiki/sql/create-view/?v=18"}],"sections":[{"paragraphs":["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."],"title":"View options"},{"paragraphs":["If the view has the security_invoker property set to true , access to the underlying base relations is determined by the permissions of the user executing the query, rather than the view owner. Thus, the user of a security invoker view must have the relevant permissions on the view and its underlying base relations.","If any of the underlying base relations is a security invoker view, it will be treated as if it had been accessed directly from the original query. Thus, a security invoker view will always check its underlying base relations using the permissions of the current user, even if it is accessed from a view without the security_invoker property.","If any of the underlying base relations has row-level security enabled, then by default, the row-level security policies of the view owner are applied, and access to any additional relations referred to by those policies is determined by the permissions of the view owner. However, if the view has security_invoker set to true , then the policies and permissions of the invoking user are used instead, as if the base relations had been referenced directly from the query using the view.","Functions called in the view are treated the same as if they had been called directly from the query using the view. Therefore, the user of a view must have permissions to call all functions used by the view. Functions in the view are executed with the privileges of the user executing the query or the function owner, depending on whether the functions are defined as SECURITY INVOKER or SECURITY DEFINER . Thus, for example, calling CURRENT_USER directly in a view will always return the invoking user, not the view owner. This is not affected by the view's security_invoker setting, and so a view with security_invoker set to false is not equivalent to a SECURITY DEFINER function and those concepts should not be confused.","Note that the user performing the insert, update or delete on the view must have the corresponding insert, update or delete privilege on the view. In addition, by default, the view's owner must have the relevant privileges on the underlying base relations, whereas the user performing the update does not need any permissions on the underlying base relations (see Section 39.5 ). However, if the view has security_invoker set to true , the user performing the update, rather than the view owner, must have the relevant privileges on the underlying base relations."],"title":"Security semantics"}]}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["15","16","17","18","19","20"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}