> 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 :) ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
