| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Andreas <e9625203(at)student(dot)tuwien(dot)ac(dot)at> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org, josh(at)agliodbs(dot)com | 
| Subject: | Re: "truncate all"? | 
| Date: | 2003-08-05 14:16:21 | 
| Message-ID: | 22159.1060092981@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Andreas <e9625203(at)student(dot)tuwien(dot)ac(dot)at> writes:
> Agreed, workarounds are easy. The original suggestion of "TRUNCATE ALL"
> (or "TRUNCATE table CASCADE"), however, was motivated by the search for a
> simple and efficient truncation of all tables to accelerate unit-testing.
I still think the best suggestion for you is the one someone made
already: create a schema dump (pg_dump -s), then do DROP DATABASE,
CREATE DATABASE, load the schema dump.  This will be somewhat slower
than a hypothetical TRUNCATE ALL, but it has the great advantage that
your starting point is well-documented and guaranteed to be the same
on every iteration.  TRUNCATE ALL would provide no such guarantee.
And, of course, that solution exists today ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-08-05 14:20:18 | Re: v7.4 Bundled ... please test ... | 
| Previous Message | Dennis Björklund | 2003-08-05 14:13:11 | cvs branch to use? |