Re: "truncate all"?
От | Stephan Szabo |
---|---|
Тема | Re: "truncate all"? |
Дата | |
Msg-id | 20030816213700.S77393-100000@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: "truncate all"? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: "truncate all"?
|
Список | pgsql-hackers |
On Sun, 17 Aug 2003, Bruce Momjian wrote: > Is this a bug? I don't think so. I'd say this is the expected behavior. Part of the point is that it fails without checking for matching rows. > Robert Treat wrote: > > On Mon, 2003-08-04 at 12:19, Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > This this a TODO? Keep in mind if we follow the syntax of VACUUM and > > > > (7.4) CLUSTER, that the all-database truncate would just be "TRUNACATE". > > > > That seems very risky to me. I wonder if the risk is worth adding this > > > > feature. > > > > > > I wouldn't care for that either. The prior suggestion of "TRUNCATE tab > > > CASCADE" (to truncate any tables with FK dependencies on the original > > > target, instead of failing) seems more reasonable. > > > > > > > Actually there seems to be an ancillary issue here: > > > > 21809=# truncate exception; > > ERROR: TRUNCATE cannot be used as table exception_notice_map references > > this one via foreign key constraint $1 > > 21809=# TRUNCATE exception_notice_map ; > > TRUNCATE TABLE > > 21809=# truncate exception; > > ERROR: TRUNCATE cannot be used as table exception_notice_map references > > this one via foreign key constraint $1 > > 21809=# select count(*) from exception_notice_map; > > count > > ------- > > 0 > > (1 row)
В списке pgsql-hackers по дате отправления: