Re: "truncate all"?

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, <shridhar_daithankar(at)persistent(dot)co(dot)in>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "truncate all"?
Date: 2003-08-04 16:03:27
Message-ID: Pine.LNX.4.33.0308041002540.10372-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I agree, a plain truncate blasting a whole database is a very bad thing.

however, "truncate with cascade" would be quite useful.

On Mon, 4 Aug 2003, Bruce Momjian wrote:

>
> This this a TODO? Keep in mind if we follow the syntax of VACUUM and
> (7.4) CLUSTER, that the all-database truncate would just be "TRUNACATE".
> That seems very risky to me. I wonder if the risk is worth adding this
> feature.
>
> ---------------------------------------------------------------------------
>
> Robert Treat wrote:
> > On Mon, 2003-08-04 at 05:40, Shridhar Daithankar wrote:
> > > On 4 Aug 2003 at 11:25, Andreas wrote:
> > > > Would it be possible to implement a "truncate all" that purges all tuples
> > > > from *all* tables, without taking account any rules or triggers, but
> > > > leaving all table structures and rules, triggers, functions, etc intact
> > > > (sequences do not need to reinitialized)?
> > > >
> > > > As far as I understand, the "no truncate if table is referenced" change was
> > > > introduced to ensure database integrity. However, if the referencing table
> > > > is truncated, too, there should be no problem as far as foreign keys are
> > > > concerned, correct?
> > > >
> > > > The rationale behind this suggestion is that in our project we need a
> > > > *quick* way to get rid of all the tuples in all tables in order to
> > > > accelerate the reinitialization of the database for our unit tests. This
> > > > needs to be done fairly often, and so the quicker the unit tests run, the
> > > > easier it will be to include many unit tests in our project, thus ensuring
> > > > that we can develop efficiently and safely in postgresql.
> > > >
> > > > If you know of some other *quick* way to truncate all tables, please let us
> > > > know. BTW: Starting and later rolling back a transaction will not work, as
> > >
> > > As a workaround, I would dump the schema to a file using pg_dump, drop the
> > > database and recreate it from schema.
> > >
> > > Will that do for you? Unfortunately that is not transaction safe and any
> > > clients connected at that time needs to disconnect first. Hopefully you can do
> > > that in the test environment.
> > >
> >
> > Truncate isn't transaction safe either, so that shouldn't be a problem.
> >
> > Proper syntax for his feature would seem like:
> > truncate table [cascade|restrict] ?
> >
> >
> > Robert Treat
> > --
> > Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2003-08-04 16:06:48 Re: Thread-safe configuration option appears to
Previous Message Peter Eisentraut 2003-08-04 15:54:41 Re: Thread-safe configuration option appears to misfunction