Re: "truncate all"?

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: "truncate all"?
Дата
Msg-id 1061130895.1709.93.camel@camel
обсуждение исходный текст
Ответ на Re: "truncate all"?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "truncate all"?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, 2003-08-17 at 00:42, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > 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.
> 
> To do anything else, you'd have to solve some locking and/or
> race-condition problems: rows could be inserted in the other table
> while the TRUNCATE runs.
> 

Seems like you'll have that issue with truncate all wont you? I guess
we'll assume that if you use the cascade statement you understand these
risks and accept them.

Really my previous email was simply to point out to anyone implementing
the truncate cascade that truncate currently doesn't care if there is
really any data in the dependent tables, just that there are dependent
tables. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: compile error on cvs tip
Следующее
От: ohp@pyrenet.fr
Дата:
Сообщение: Re: UnixWare on Current CVS: Success!