On Thursday 06 May 2004 11:47, scott.marlowe wrote:
> On Thu, 6 May 2004, Richard Huxton wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > >>Richard Huxton <dev@archonet.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?
What about rules/views/functions and who knows what else (domains?) might be
dependant on the current type definition? It seems like a pretty big can of
worms really.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
