| 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? |