From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Subject: | Re: about truncate |
Date: | 2009-01-08 15:46:19 |
Message-ID: | 20090108154618.GA1475@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 08, 2009 at 02:39:52PM +0200, Peter Eisentraut wrote:
> David Fetter wrote:
>> +1 for adding recursion to GRANT/REVOKE :)
>
> This area is under SQL standard control, so we can't really invent our
> own behavior.
>
> Consider the following:
>
> CREATE TABLE persons (name, email);
> CREATE TABLE employees (grade, salary) INHERITS (persons);
>
> GRANT SELECT ON persons TO allstaff; -- ???
> GRANT SELECT ON employees TO managers;
>
> What you want in practice is that allstaff can read only those columns
> of employees that come from the persons table. Both recursive and
> nonrecursive GRANT do the wrong thing here.
What *would* do the right thing here, or would anything?
Cheers,
David (not getting into the design decisions implicit in the above
tables, which IMHO is not right)
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-08 15:49:20 | Re: Open item: kerberos warning message |
Previous Message | Magnus Hagander | 2009-01-08 15:41:57 | Open item: kerberos warning message |