Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Peter Eisentraut wrote:
> >> Considering that TRUNCATE is a pretty dangerous operation, how can we
> >> make adjustments to the behavior without upsetting lots of users?
>
> > Well, it is one of those, "Either we fix it or live with the
> > inconsistency forever". Historically we have opted to fix it with a
> > clear warning in the major release notes.
>
> The only alternatives I can see are
>
> (1) go ahead and change it.
>
> (2) invent a separate "truncate_inheritance" GUC that is just like
> "sql_inheritance" except it applies only for TRUNCATE.
>
> Ugly as (2) is, I think it just puts off the pain. Sooner or later
> we'd want to flip the factory default from false to true, and the
> release that does that is *still* going to burn anyone who's not
> paying attention to the release notes.
The only way I think #2 works is if we say the GUC will disappear in the
next major release, but it hardly seems worth adding the GUC because few
people have even noticed the current behavior is a problem, meaning they
are probably not using it for parent truncation often.
> 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.
>
> 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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
