Skip site navigation (1) Skip section navigation (2)


From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE TODO items
Date: 2004-05-06 15:47:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
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 MoncureDate: 2004-05-06 15:55:29
Subject: alter table alter columns vs. domains
Previous:From: sdv mailerDate: 2004-05-06 15:30:01
Subject: Re: PostgreSQL pre-fork speedup

pgsql-committers by date

Next:From: Tom LaneDate: 2004-05-06 16:10:57
Subject: pgsql-server/src backend/commands/cluster.c ba ...
Previous:From: Tom LaneDate: 2004-05-06 14:01:33
Subject: pgsql-server/src backend/nodes/outfuncs.c back ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group