Re: TRUNCATE

> A limited-to-that-table dump/fix/restore can be a problem because of
the
> interrelationships of RI among tables. If there were any easier way
to dump
> information about a table so that I could restore the RI that other
tables
> have on it, that might be a solution.

Agreed about making that easier.

> > What do you use to clean it up? Custom script for each job?
Regular
> > expressions? Simple spreadsheet like format filling in numbers?
> > Complete dump and replace of the data?
>
> Generally, I'm doing something like pulling the data into a text
file and
> using regexes or spreadsheet tools to clean it up. Some of which
could be
> done (through plperl or plpython or such), but is often easier with
full
> text manipulation/emacs/etc.

Internal regex support would be useful, as would plpgsql from anywhere
(merge most into standard frontend parser).

> Sometimes, though, I'm just cleaning out test data. For example:
often, I'll
> create a table where records can't be deleted w/out logging
information

You don't create database testdb with template = productiondb?
Especially since you take it offline anyway.

> that there were triggers/rules/RI or (better) requiring a FORCE
parameter to
> truncate when there are might make others feel safe, though.

FORCE doesn't really solve the issue for me. I want to remove the
ability to unexpectedly mess up the database. They're usually good
enough to know that drop database is a bad thing. But some of the
other commands have interesting seemingly non-related failures.
Truncate was one, object inter-dependence (what pg_depend covers) was
another area.

Anyway, I'm willing to wait until I (or someone else) can remove the
advantages of truncate over other methods :)