Re: Column-Level Privileges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Column-Level Privileges
Date
Msg-id 17853.1233705846@sss.pgh.pa.us
Whole thread Raw
In response to Re: Column-Level Privileges  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Column-Level Privileges  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> * Some of the information_schema views are specified to respond to
>> per-column privileges; the column_privileges and columns views
>> certainly need work now to meet spec, and there might be others.

> Done.

I looked through the spec a bit.  If I'm reading it right, these
views should show columns that you have either table-level or
column-level privilege for:column_privilegescolumnskey_column_usagerole_column_grants

What's more, these views should show you tables/views that you have
column privilege on any column of, even if you haven't got any
full-table privileges:tablestable_constraintstable_privilegesviews

I thought about handling the tests for the latter by exposing
pg_attribute_aclcheck_all() as a function named something like
has_any_column_privilege().  However, that would amount to forcing a
nestloop-with-inner-indexscan join to pg_attribute for any table you
didn't have full-table privileges for; also it would bloat the syscache
in a database with lots of tables.  It might be better to expose that
join explicitly and let the planner try to decide what to do.  OTOH
I don't think the planner would be very smart about avoiding the join
if you do have full-table privileges.  Either way you slice it it could
be really slow :-(

Comments, better ideas?  Does anyone think I misread the spec?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: LIMIT NULL
Next
From: Robert Haas
Date:
Subject: Re: Column-Level Privileges