Re: "truncate all"?

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "truncate all"?
Date: 2003-08-04 16:53:32
Message-ID: 1060016013.22273.1812.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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.
>
> I wouldn't care for that either. The prior suggestion of "TRUNCATE tab
> CASCADE" (to truncate any tables with FK dependencies on the original
> target, instead of failing) seems more reasonable.
>

Actually there seems to be an ancillary issue here:

21809=# truncate exception;
ERROR: TRUNCATE cannot be used as table exception_notice_map references
this one via foreign key constraint $1
21809=# TRUNCATE exception_notice_map ;
TRUNCATE TABLE
21809=# truncate exception;
ERROR: TRUNCATE cannot be used as table exception_notice_map references
this one via foreign key constraint $1
21809=# select count(*) from exception_notice_map;
count
-------
0
(1 row)

21809=#

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 2003-08-04 16:56:13 Re: problem with RH7.3 Pg7.3.4 binaries
Previous Message Larry Rosenman 2003-08-04 16:52:33 Re: Thread-safe configuration option appears to