Re: TRUNCATE
От | Rod Taylor |
---|---|
Тема | Re: TRUNCATE |
Дата | |
Msg-id | 001601c1fade$b2b9f6a0$8001a8c0@jester обсуждение исходный текст |
Ответ на | Re: TRUNCATE ("Joel Burton" <joel@joelburton.com>) |
Список | 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 :)
В списке pgsql-hackers по дате отправления: