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