Re: Proposal: TRUNCATE TABLE table RESTRICT
От | Don Baccus |
---|---|
Тема | Re: Proposal: TRUNCATE TABLE table RESTRICT |
Дата | |
Msg-id | 3.0.1.32.20000608075551.01164e40@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: Proposal: TRUNCATE TABLE table RESTRICT (Mike Mascari <mascarm@mascari.com>) |
Ответы |
Re: Proposal: TRUNCATE TABLE table RESTRICT
|
Список | 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 по дате отправления: