Re: about truncate

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

In response to

Responses

Browse pgsql-hackers by date

  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