On Thu, 6 May 2004, Richard Huxton wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >>Richard Huxton <dev(at)archonet(dot)com> writes:
> >>>Does that mean I'll want to disable triggers while I do this?
> >>Hrm. Right now the code does not fire triggers at all, but that seems
> >>wrong. However, I doubt that very many triggers could cope with update
> >>events in which the old and new rows have different rowtypes :-(.
> >>Any thoughts what to do about that?
> > If triggers exist, I think we should just throw a warning that triggers
> > will not be fired.
> Tom's point about triggers probably not working after the upgrade is a
> good one though. Is it reasonable to just refuse to act on a table until
> all triggers are dropped? I'd rather be forced to go through and
> drop/restore triggers in a script than be surprised later on.
How about "cascade drop triggers" as an option so you can still do it in
one line should you want to?
In response to
pgsql-hackers by date
|Next:||From: Merlin Moncure||Date: 2004-05-06 15:55:29|
|Subject: alter table alter columns vs. domains|
|Previous:||From: sdv mailer||Date: 2004-05-06 15:30:01|
|Subject: Re: PostgreSQL pre-fork speedup|
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2004-05-06 16:10:57|
|Subject: pgsql-server/src backend/commands/cluster.c ba ...|
|Previous:||From: Tom Lane||Date: 2004-05-06 14:01:33|
|Subject: pgsql-server/src backend/nodes/outfuncs.c back ...|