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.20000608075034.0116ebd0@mail.pacifier.com
Whole thread Raw
In response to Re: Proposal: TRUNCATE TABLE table RESTRICT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 10:41 AM 6/8/00 -0400, Tom Lane wrote:
>Don Baccus <dhogaza@pacifier.com> writes:
>> If the references are implicit (no REFERENCE or FOREIGN KEY given
>> to inform the db of the relationship) then a RESTRICT option to
>> truncate does seem useful.
>
>Uh, if the references are implicit, how would RESTRICT know they exist?

Duh, sorry, haven't had my coffee yet.  I should know better than
think about computers before coffee...got any?

OK ... then I'd suggest that allowing truncate in the face of explicit
foreign keys is a bug.  Truncate should either refuse to do so in
all cases, or follow RI rules (do ON DELETE CASCADE/SET NULL/SET DEFAULT
or refuse to do it depending on the foreign key def).  It would
presumably do so by calling the RI trigger for each row just as delete
does.

TRUNCATE's documented as being a quick alternative to delete,
so refusal is perhaps the best course.  Or the documentation
can say "it's a lot faster if there are no foreign keys referencing
it, otherwise it's the same as DELETE FROM".

But breaking RI by leaving "dangling references" is a bug, pure
and simple.




- 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: Travis Bauer
Date:
Subject: implements jdbc2's getArray(int)
Next
From: Don Baccus
Date:
Subject: Re: Proposal: TRUNCATE TABLE table RESTRICT