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: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, 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-17 14:34:55
Message-ID: 1061130895.1709.93.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2003-08-17 at 00:42, Tom Lane wrote:
> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > On Sun, 17 Aug 2003, Bruce Momjian wrote:
> >> Is this a bug?
>
> > I don't think so. I'd say this is the expected behavior. Part of the
> > point is that it fails without checking for matching rows.
>
> To do anything else, you'd have to solve some locking and/or
> race-condition problems: rows could be inserted in the other table
> while the TRUNCATE runs.
>

Seems like you'll have that issue with truncate all wont you? I guess
we'll assume that if you use the cascade statement you understand these
risks and accept them.

Really my previous email was simply to point out to anyone implementing
the truncate cascade that truncate currently doesn't care if there is
really any data in the dependent tables, just that there are dependent
tables.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ohp 2003-08-17 15:00:38 Re: UnixWare on Current CVS: Success!
Previous Message Bruce Momjian 2003-08-17 13:29:20 Re: compile error on cvs tip