From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | "Joel Burton" <joel(at)joelburton(dot)com> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TRUNCATE |
Date: | 2002-05-14 00:31:31 |
Message-ID: | 001601c1fade$b2b9f6a0$8001a8c0@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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 :)
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-05-14 00:33:58 | Re: pg_dump DROP commands and implicit search paths |
Previous Message | Rod Taylor | 2002-05-13 23:42:27 | Re: pg_dump DROP commands and implicit search paths |