Re: "truncate all"? - Mailing list pgsql-hackers
From | Andreas |
---|---|
Subject | Re: "truncate all"? |
Date | |
Msg-id | 5.2.0.9.0.20030806103245.00b40c50@stud4.tuwien.ac.at Whole thread Raw |
In response to | Re: "truncate all"? (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: "truncate all"?
|
List | pgsql-hackers |
Hi there, At 17:55 05.08.2003, Josh Berkus wrote: > > Another way to specify a safe but efficient "TRUNCATE ALL" command that > > might be easier to implement than above "TRUNCATE table > > [CASCADE|RESTRICT]" might be to implement the functionality of the > > originally suggested "TRUNCATE ALL" through a psql meta-command. Any > > suggestions for a safe syntax of such a "TRUNCATE ALL" meta-command? How > > about "\rtuples *"? > >I'm not clear on the usefulness of this idea. If we agree that TRUNCATE ... >CASCADE is needed, then doing it in SQL makes sense. Your suggested command >would leave itself open to typo-death. How about using a command name that is long enough so that mistyping becomes highly unlikely? The following might be exaggerated, but why not call it something like \removealltuplesofalltableswithoutcheckingreferentialintegrity (please take it with a grain of salt 8-). Both this meta-command and the TRUNCATE table CASCADE command make sense separately as extensions to psql, as their motivations are quite different. For the purpose of unit-tests, only the first would make sense since there we need to truncate all tables anyway and as the latter would only generate unnecessary overhead. Unit-tests must run as fast as possible as we want to rely on them for every editing step. >And if we have TRUNCATE ... CASCADE, then truncating all tables is a >matter of >a very simple perl or C script looping through pg_class. Sure, but I would imagine that a truncation of all tuples of every table in the db, for (1), would be very simple to implement since we can forget about all dependencies, and, for (2), would be decidedly faster than calling TRUNCATE table CASCADE repeatedly, because there is no need to switch languages and no need to find out about dependencies as a first step. As an aside, I wonder whether a cascading truncate needs to be made safe against table-level cyclicity w.r.t. referential integrity? >I also don't think that outside of your particular >case that there's much demand for it; I would like to believe that there is a need for efficient unit-testing (unit-tests can be seen as a kind of regression tests for applications) in postgresql beyond our project. If developers are not using unit-tests (yet), I would also like to believe that this should not be interpreted as an indication that they do not want to use them, but maybe that they do not know about them. Thanks for your time, Andi.
pgsql-hackers by date: