Re: about truncate - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: about truncate
Date
Msg-id 871vvpr1b1.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: about truncate  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:

> Tom Lane wrote:
>> My vote is to just go ahead and change it.  I don't really see much
>> of a use-case for truncating only the parent of an inheritance
>> hierarchy anyway, so I doubt that many people would be affected.

agreed.

>> I note though that we have a lot of other non-recursive maintenance
>> operations (CLUSTER, some variants of ALTER TABLE, etc) ... are we
>> going to try to make them all recursive?
>
> Uh, good question.  ;-)  I think fixing TRUNCATE makes sense because it
> is similar to DELETE (it operates on the data), but I see ALTER TABLE
> and CLUSTER as per-table operations that people would not expect to ever
> recurse, i.e. TRUNCATE is like DELETE without a WHERE clause, but
> CLUSTER or ALTER TABLE have no DML equivalents.

What does the standard say about ALTER TABLE and inheritance? It seems like it
would be hard to make ALTER TABLE recursive since, while some operations might
make sense, others will depend on the current state of the table and that
might be very different for different children.

Likewise CLUSTER ON/USING doesn't make much sense to be recursive since the
index names will be different. It might be handy to have a recursive version
of the command to recluster an already clustered table though.


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: incoherent view of serializable transactions
Next
From: "Kevin Grittner"
Date:
Subject: Re: Documenting serializable vs snapshot isolation levels