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.20000612071517.0119a210@mail.pacifier.com
Whole thread Raw
In response to Re: Proposal: TRUNCATE TABLE table RESTRICT  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
At 08:08 PM 6/10/00 +0200, Peter Eisentraut wrote:
>Tatsuo Ishii writes:
>
>> That would be better. I am just wondering how the checkings hurt the
>> speed of TRUNCATE (if TRUNCATE is that slow, why we need it:-).
>
>You can make any code arbitrarily fast if it doesn't have to behave
>correctly. :-)

Checking for existence or absence of triggers will be fast.

Jan suggested aborting TRUNCATE if any (user or system) triggers
are on the table.  If I understood his message correctly, that is.

Oracle only aborts for foreign keys, executing TRUNCATE and ignoring
user triggers if they exist.

Any thoughts?

Rather than abort TRUNCATE due to the mere existence of a referential
integrity trigger on the table, we could be a bit more sophisicated
and only abort if an RI trigger exists where the referring table is
non-empty.  If the referring table's empty, no foreign keys will be
stored in it and you can safely TRUNCATE.




- 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: Karel Zak
Date:
Subject: CVS: bug in odbc Makefiles
Next
From: Mike Mascari
Date:
Subject: Re: Proposal: TRUNCATE TABLE table RESTRICT