Re: about truncate

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

In response to

Responses

Browse pgsql-hackers by date

  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