From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-20 22:09:41 |
Message-ID: | 49764BA5.8030007@dunslane.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:
>
>> The SQL standard uses a recursive-by-default language. For example, the
>> rules for the DELETE command state:
>>
>
> Actually, I'm not convinced. Take a look at the SELECT WITH HIERARCHY
> OPTION stuff in SQL99 and later, in particular this from SQL99
> 12.2 <grant privilege statement>:
>
> 7) Let SWH be the set of privilege descriptors in CPD whose action
> is SELECT WITH HIERARCHY OPTION, and let ST be the set of
> subtables of O, then for every grantee G in SWH and for every
> table T in ST, the following <grant statement> is effectively
> executed without further Access Rule checking:
>
> GRANT SELECT ON T TO G GRANTED BY A
>
> It's difficult to read that any other way than that privileges are *not*
> auto-recursive, and they have chosen to spell "*" in GRANT as "WITH
> HIERARCHY OPTION" (gackk).
>
> On the other hand, it's hard to square that reading with the lack of any
> UPDATE or DELETE WITH HIERARCHY OPTION syntax. What am I missing here?
>
>
>
It's just occurred to me that if TRUNCATE no longer means TRUNCATE ONLY,
parallel restore will need to detect which server version is being used
so that for version > 8.3 it issues TRUNCATE ONLY. Otherwise there would
be a danger of a collision between a table and its children. The only
alternative would be to create a dependency between the data of a table
and the data of its children, which would be undesirable as well as more
complicated - in general the data should only depend on the table
creation (at most).
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-01-20 22:13:53 | Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector |
Previous Message | Bruce Momjian | 2009-01-20 21:54:48 | Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector |