Re: column level privileges

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-patches(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: column level privileges
Date: 2008-05-07 11:33:59
Message-ID: 200805071334.00350.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Am Mittwoch, 7. Mai 2008 schrieb Tom Lane:
> >> 1.1 Add a column named 'attrel' in pg_attribute catalog to store
> >> column privileges. Now all column privileges are stored, no matter
> >> whether they could be implied from table-level privilege.
>
> What this actually means, but doesn't say, is that there's no
> table-level representation of INSERT/UPDATE privilege any more at all.
> I think this is a pretty fundamental design error.  In the first place
> it bloats pg_attribute with data that's entirely redundant for the
> "typical" case where per-column privileges aren't used.  In the
> second place it slows privilege checking for the typical case, since
> instead of one check for the relation you have to do one for each
> attribute.  There are some other problems too, like having to extend
> pg_shdepend to include an objsubid column, and some other places where
> the patch has to do awkward things because it's now lacking table-level
> information about privilege checks.

I haven't read the patch, but there is also a semantic issue, namely what
happens to columns added after the grant. If the GRANT was to the table, new
columns should get the same privileges.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2008-05-07 11:38:33 Re: column level privileges
Previous Message Simon Riggs 2008-05-07 11:05:59 Re: Concurrent psql API

Browse pgsql-patches by date

  From Date Subject
Next Message Stephen Frost 2008-05-07 11:38:33 Re: column level privileges
Previous Message Simon Riggs 2008-05-07 11:05:59 Re: Concurrent psql API