Re: Re: pg_dump scripts are no longer ordinary-user friendly

On Mon, 5 Mar 2001, Tom Lane wrote:

> Philip Warner <pjw@rhyme.com.au> writes:
> > At 21:37 5/03/01 -0500, Tom Lane wrote:
> >> Philip Warner <pjw@rhyme.com.au> writes:
> >>> ... we could go back to the old model of only updating
> >>> pg_class in a data-only dump/restore.
> >> 
> >> Works for me ...
> 
> > Should we have an option to turn off this feature entirely?
> 
> Now that you mention it, is it a feature at all?  Or a bug?  ISTM poor
> form for a data-only restore to assume it may turn off all pre-existing
> triggers.

The problem is that in general if you do a schema dump and data dump
separately (which was the case that was put in for really), you're already
screwed if you've got triggers that alter or check other data unless
you do manual work for restore.

If you've got a trigger that logs changes, you don't want to log the 
reinserted data if you're also restoring the data for the log table.
You can't not restore the log table if it logs modifications because
you'll lose the modification data.

If you're doing any triggers that are doing anything like fk (say you
want to do something other than direct comparisons) you run into the
issue of having the data not be there.

If you're doing an insert/update trigger that sets a modification date,
you probably don't want to blow away the modification dates on a restore.

I don't think turning off triggers is a good idea, but I'm not certain
that turning them on always will actually be better for the average user.  
I think an option is a good idea though.