<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Column_privileges on Postgres Scripts</title><link>https://www.postgresscripts.com/tags/column_privileges/</link><description>Recent content in Column_privileges on Postgres Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>PostgresScripts.com</copyright><lastBuildDate>Sat, 06 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.postgresscripts.com/tags/column_privileges/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL Column-Level Permissions Audit Query</title><link>https://www.postgresscripts.com/post/postgresql-column-level-permissions-with-information-schema-column-privileges/</link><pubDate>Sat, 06 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.postgresscripts.com/post/postgresql-column-level-permissions-with-information-schema-column-privileges/</guid><description>
&lt;h2 id="postgresql-column-level-permissions-audit-query"&gt;PostgreSQL Column-Level Permissions Audit Query&lt;/h2&gt;
&lt;p&gt;Which roles can read which columns? Table-level grants are easy to list, but they hide a finer layer of access. A role denied &lt;code&gt;SELECT&lt;/code&gt; on a table can still hold &lt;code&gt;SELECT&lt;/code&gt; on two of its columns, and that is exactly where personal data quietly stays reachable after a wider grant is revoked. The &lt;code&gt;information_schema.column_privileges&lt;/code&gt; view answers the column-level question directly: every grantee, every column, every privilege, in one query.&lt;/p&gt;</description></item></channel></rss>