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 <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend