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.
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 |