From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, 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-12 09:50:33 |
Message-ID: | 496B1269.9060101@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>>> This area is under SQL standard control, so we can't really invent our
>>>> own behavior.
>
>>> What *would* do the right thing here, or would anything?
>
>> I think we don't need GRANT to be recursive, but instead the permission
>> checks at runtime should allow
>> SELECT * FROM persons;
>> to succeed even if there are no permissions on "employees".
>
> Hmm, if we are supposing that the spec should control this, then
> surely we can find chapter and verse spelling out what should happen.
The SQL standard uses a recursive-by-default language. For example, the
rules for the DELETE command state:
"""
6) Case:
a) If <target table> contains ONLY, then the rows for which the result
of the <search condition> is True
and for which there is no subrow in a proper subtable of T are
identified for deletion from T.
b) Otherwise, the rows for which the result of the <search condition> is
True are identified for deletion
from T.
"""
So when the SQL standard says, privileges are granted on this table, or
$action is done on that table, it means, in PostgreSQL terms, the table
and its children.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-01-12 10:06:23 | Re: foreign_data test fails with non-C locale |
Previous Message | Peter Eisentraut | 2009-01-12 09:47:34 | Re: about truncate |