{"kind": "relopts", "major": "18", "item": {"slug": "view-security-barrier", "name": "security_barrier", "name_zh": "security_barrier", "category": "View options", "summary": "This should be used if the view is intended to provide row-level security. See Section 39.5 for full details.", "aliases": ["view.security_barrier"], "versions": {"10": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=10", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 10.23", "label": "10.23", "major": "10", "channel": "historical", "revision": "4ff6f6193d91bf44fc701f657cc3295850bf786e42eafbfeed9f4879c3522613"}, "sources": [{"url": "/docs/10/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 10 English manual", "sha256": "f3beb72fc3c516331a0c0535d13aa59329eb7fdc265b20945dc7a37b97cfed4a"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 40.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 40.5 for full details."]}, "11": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=11", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 11.22", "label": "11.22", "major": "11", "channel": "historical", "revision": "284f2186559443efefbb1ea3b00740c25dccd01e540ecbdb81dadf5127e54a0b"}, "sources": [{"url": "/docs/11/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 11 English manual", "sha256": "cb691ccbc81965b50e4404c037e081b1038886bed54a2da7ed28d083ff11becd"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 41.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 41.5 for full details."]}, "12": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=12", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 12.22", "label": "12.22", "major": "12", "channel": "historical", "revision": "0a1032bc0c23478646e9ee7d36edb066dca27b8540fd64d7fd47dcb6a8a6ccb4"}, "sources": [{"url": "/docs/12/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 12 English manual", "sha256": "30c56ff14a8865b60f2954e70821eb7a6187fb35c2140b4c5697894b6f24bc9e"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 40.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 40.5 for full details."]}, "13": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=13", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 13.23", "label": "13.23", "major": "13", "channel": "historical", "revision": "346825c2d5fbebb2bd997afbb2d49edfd782dce050c0b934e84a883e5446a99f"}, "sources": [{"url": "/docs/13/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 13 English manual", "sha256": "99ec0fd97653a0486c7d2575acc9713f73e2a9b12464e4dfa0b2046e772fd111"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 40.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 40.5 for full details."]}, "14": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=14", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 14.24", "label": "14.24", "major": "14", "channel": "stable", "revision": "b6e7ed6d017bf1d63aae215156cde763babd657199df9fa10123733290c31260"}, "sources": [{"url": "/docs/14/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 14 English manual", "sha256": "ce32f28c1a1e064f26c167a63d68b7d3dd61213f16597c23a377f5c0fcfd3155"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 41.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 41.5 for full details."]}, "15": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=15", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 15.19", "label": "15.19", "major": "15", "channel": "stable", "revision": "643ecd492fa284d4d55861f15cbd7c0c7451abce96c8d56485bb2729caba37d5"}, "sources": [{"url": "/docs/15/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 15 English manual", "sha256": "5e264be14c16e87295e86ed356aea640f7a46a5a5fe713dc20c903e8301d690c"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 41.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 41.5 for full details."]}, "16": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=16", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 16.15", "label": "16.15", "major": "16", "channel": "stable", "revision": "0080d7d37081f27216dc4aa4f6ad85ea24c0c0441e702e6d0b190a339fd76f62"}, "sources": [{"url": "/docs/16/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 16 English manual", "sha256": "4b881ea4898cc76b99becc82db07c4f45d51eb92566127d308b676625b4d06fd"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 41.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 41.5 for full details."]}, "17": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=17", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 17.11", "label": "17.11", "major": "17", "channel": "stable", "revision": "440f894c3464e7cb4fedc9846b948ca21cd2ffcef1697ff56a28eb641ee7c3d8"}, "sources": [{"url": "/docs/17/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 17 English manual", "sha256": "80b0ff1f7c82a347bb322670817b6cc38c71b249f6b49163dcdd80f3bbd184a4"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 39.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 39.5 for full details."]}, "18": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=18", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 18.6", "label": "18.6", "major": "18", "channel": "stable", "revision": "eb6c2292fdf28e1b4635ab478eec3919411cdf4a6c07553387870e26201f3744"}, "sources": [{"url": "/docs/18/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 18 English manual", "sha256": "0c11551250a39c2136437e8cded6bcb5bb8d324fa60b9b2e86b2276ad60ee599"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 39.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 39.5 for full details."]}, "19": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=19", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 19 beta 4", "label": "19 beta 4", "major": "19", "channel": "preview", "revision": "df6d20830d1a09734a2db6ffc3a6138ce80e669294e56a30f6b5d4a89d81aef1"}, "sources": [{"url": "/docs/19/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 19 English manual", "sha256": "eb32d7fd0cdf4f868af1a1a1c866aabe70295e50e327b97c9577a944a6092a79"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 39.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 39.5 for full details."]}, "20": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=20", "label": "CREATE VIEW"}], "release": {"ref": "2c10c2ce4d7bcd57543a49ab402af02a39724e0a", "label": "20 devel", "major": "20", "channel": "devel", "revision": "ca199fbaaf6c4bd29cd5a98beaf34d9f4141c15d2f94d1d0202f3204ef18d09f"}, "sources": [{"url": "/docs/devel/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 20 English manual", "sha256": "ab4714c547b7e5dc1c3730b0702032f40e58945b0078a5ea5de9f8644c1154ee"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 39.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 39.5 for full details."]}}, "content_hash": "5db22005bb39a4f721f6ec732ca2b40c1a41055755991be7ed5acc9641a0c910", "imported_at": "2026-09-27T09:57:59.035"}, "snapshot": {"facts": [{"label": "Applies to", "value": "View options"}, {"label": "Value type", "value": "boolean"}], "related": [{"url": "/docs/sql/create-view/?v=18", "label": "CREATE VIEW"}], "release": {"ref": "Local English manual 18.6", "label": "18.6", "major": "18", "channel": "stable", "revision": "eb6c2292fdf28e1b4635ab478eec3919411cdf4a6c07553387870e26201f3744"}, "sources": [{"url": "/docs/18/sql-createview.html", "path": "sql-createview.html", "label": "PostgreSQL 18 English manual", "sha256": "0c11551250a39c2136437e8cded6bcb5bb8d324fa60b9b2e86b2276ad60ee599"}], "sections": [{"title": "View options", "paragraphs": ["Views do not store query results. Set these security or update semantics with CREATE VIEW WITH or ALTER VIEW."]}, {"title": "Security semantics", "paragraphs": ["If an automatically updatable view is marked with the security_barrier property then all the view's WHERE conditions (and any conditions using operators which are marked as LEAKPROOF ) will always be evaluated before any conditions that a user of the view has added. See Section 39.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the user's WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not."]}], "signature": "WITH (security_barrier = value)", "description": ["This should be used if the view is intended to provide row-level security. See Section 39.5 for full details."]}, "comparison": {"left": "17", "right": "18", "status": "unchanged", "diff": ""}}