Re: Proposal: TRUNCATE TABLE table RESTRICT - Mailing list pgsql-hackers

From Don Baccus
Subject Re: Proposal: TRUNCATE TABLE table RESTRICT
Date
Msg-id 3.0.1.32.20000608075551.01164e40@mail.pacifier.com
Whole thread Raw
In response to Re: Proposal: TRUNCATE TABLE table RESTRICT  (Mike Mascari <mascarm@mascari.com>)
Responses Re: Proposal: TRUNCATE TABLE table RESTRICT  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
At 10:43 AM 6/8/00 -0400, Mike Mascari wrote:

>Just curious, Don. But could you check to see what Oracle's
>behavior is on this? That's the feature I was trying to mirror.
>At the time, RI wasn't integrated so I wasn't thinking about this
>issue.

Sure, I understand.

> And the Oracle docs state that DML triggers aren't fired
>when a TRUNCATE is issued, so I didn't think there would be
>issues there. Could you check?

It refuses to do the TRUNCATE, whether or not there's a
"ON DELETE CASCADE" modifier to the references.

That seems reasonable - it allows one to still say "truncate's
really fast because it doesn't scan the rows in the table",
and refuses to break RI constraints.

All that needs doing is to check for the existence of 
at least one RI trigger on the table that's being truncated,
and saying "no way, jose" if we want to mimic Oracle in
this regard.

TODO item?



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: Proposal: TRUNCATE TABLE table RESTRICT
Next
From: Brian E Gallew
Date:
Subject: index idea for system catalogs