On Tue, Dec 30, 2008 at 11:50:06AM -0500, 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.
>
> 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.
Here's one such use-case. Let's say a table has gotten large and
you've decided to partition it. You add child tables, add one or more
triggers to the parent table to make sure it never gets a row,
populate the child tables from the parent table, then you want to
remove all the rows from the parent table.
TRUNCATE ONLY handles this case just fine, so long as there's a clear
message in the release notes. :)
> 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?
We probably should.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
