Re: Proposal: TRUNCATE TABLE table RESTRICT

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Mike Mascari <mascarm(at)mascari(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: TRUNCATE TABLE table RESTRICT
Date: 2000-06-12 23:51:20
Message-ID: 3.0.1.32.20000612165120.01172870@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 07:48 PM 6/12/00 -0400, Mike Mascari wrote:

>Actually, I was worried that if TRUNCATE were to vist all
>referring tables to determine whether or not it was empty, rather
>then just issuing an elog() at the first RI trigger encountered,
>that it might wind up scanning a 1,000,000 tuple relation (the
>referring relation) where all the rows have been marked as
>deleted before determining that its okay to perform the TRUNCATE.
>I was hoping that Oracle simply disallowed TRUNCATE on tables
>with referring relations, regardless of whether or not there was
>actually any data in them, so that PostgreSQL could do the same.
>:-)

Well, I think we probably could do so regardless of what Oracle
does. Proper use of "on delete cascade" and "on delete set null"
etc would seem to make it more convenient to delete rows in a
set of related tables via delete rather than running around
trying to truncate them in the right order so that you
end up with empty tables before you delete the one with the
RI triggers on it.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Bitmead 2000-06-13 00:04:11 Re: ALTER TABLE DROP COLUMN
Previous Message Mike Mascari 2000-06-12 23:48:59 Re: Proposal: TRUNCATE TABLE table RESTRICT