Re: about truncate

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.

In response to

Responses

Browse pgsql-hackers by date

  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