Обсуждение: ALTER TRIGGER DISABLE/ENABLE
Hello, while there have been suggested some hacks on the system catalog for disabling/enabling triggers, these have two serious disadvantages: - they cannot be done by the owner of the trigger (only the DBA has write access to the system catalog) - messing in the system catalog for simple DB schema changes makes most users feel uneasy Oracle has an SQL command "ALTER TRIGGER triggername DISABLE|ENABLE". Were it possible to put this command on the TODO list for a future PG release? Thanks, Christoph Dalitz
Hello friends ! Anybody has 7.2.3 rpms for RH 8.0 ? Thank you Andy
try www.rpmfind.net Andy Samuel schrieb: >Hello friends ! > >Anybody has 7.2.3 rpms for RH 8.0 ? > >Thank you >Andy > > > > >---------------------------(end of broadcast)--------------------------- >TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > >
Hi, --On Dienstag, 26. November 2002 09:43 +0100 Christoph Dalitz <christoph.dalitz@hs-niederrhein.de> wrote: > Hello, > > while there have been suggested some hacks on the system catalog > for disabling/enabling triggers, these have two serious disadvantages: > > - they cannot be done by the owner of the trigger > (only the DBA has write access to the system catalog) > - messing in the system catalog for simple DB schema changes makes > most users feel uneasy > > Oracle has an SQL command "ALTER TRIGGER triggername DISABLE|ENABLE". > Were it possible to put this command on the TODO list for a future PG > release? Sounds reasonable, but should a form ALTER TABLE DISABLE|ENABLE [ALL] TRIGGER or something like that be available too? This could be done for RI-Triggers on a table while restoring data. Regards Tino
Christoph Dalitz wrote:
> Hello,
>
> while there have been suggested some hacks on the system catalog
> for disabling/enabling triggers, these have two serious disadvantages:
>
> - they cannot be done by the owner of the trigger
> (only the DBA has write access to the system catalog)
> - messing in the system catalog for simple DB schema changes makes
> most users feel uneasy
>
> Oracle has an SQL command "ALTER TRIGGER triggername DISABLE|ENABLE".
> Were it possible to put this command on the TODO list for a future PG release?
Already on TODO list:
* Allow triggers to be disabled [trigger]
I will add your email to the TODO.detail thread.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
I think thte sintax should be:
ALTER TABLE DISABLE|ENABLE TRIGGER {trigger name}|ALL
Bruce Momjian wrote:
>
> Christoph Dalitz wrote:
> > Hello,
> >
> > while there have been suggested some hacks on the system catalog
> > for disabling/enabling triggers, these have two serious disadvantages:
> >
> > - they cannot be done by the owner of the trigger
> > (only the DBA has write access to the system catalog)
> > - messing in the system catalog for simple DB schema changes makes
> > most users feel uneasy
> >
> > Oracle has an SQL command "ALTER TRIGGER triggername DISABLE|ENABLE".
> > Were it possible to put this command on the TODO list for a future PG release?
>
> Already on TODO list:
>
> * Allow triggers to be disabled [trigger]
>
> I will add your email to the TODO.detail thread.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
On Tue, 26 Nov 2002 14:41:47 -0500
Jean-Luc Lachance <jllachan@nsd.ca> wrote:
>
> I think thte sintax should be:
>
> ALTER TABLE DISABLE|ENABLE TRIGGER {trigger name}|ALL
>
This would make no sense:
It could be the syntax if the statement for creating a trigger
where "ALTER TABLE ADD TRIGGER".
The statement for creating a trigger is however "CREATE TRIGEER".
Consequently the statement for changing a trigger must be "ALTER TRIGGER"
and not "ALTER TABLE".
Switching off all triggers for an individual table at once would be
convenient of course and can be easily achieved with "ALTER TRIGGER" as well:
just write a little PL/SQL procedure "disable_triggers()" that takes a
tablename as input and disables all triggers on it.
Christoph Dalitz
Sementics.
The trigger belongs to the table.
The trigger is not modified.
The ability of the table being modified to call it is modified.
Plus, if you want all the triggers on a table to be disabled the ALTER
TRIGGER is not enough.
JLL
Christoph Dalitz wrote:
>
> On Tue, 26 Nov 2002 14:41:47 -0500
> Jean-Luc Lachance <jllachan@nsd.ca> wrote:
> >
> > I think thte sintax should be:
> >
> > ALTER TABLE DISABLE|ENABLE TRIGGER {trigger name}|ALL
> >
> This would make no sense:
>
> It could be the syntax if the statement for creating a trigger
> where "ALTER TABLE ADD TRIGGER".
>
> The statement for creating a trigger is however "CREATE TRIGEER".
>
> Consequently the statement for changing a trigger must be "ALTER TRIGGER"
> and not "ALTER TABLE".
>
> Switching off all triggers for an individual table at once would be
> convenient of course and can be easily achieved with "ALTER TRIGGER" as well:
> just write a little PL/SQL procedure "disable_triggers()" that takes a
> tablename as input and disables all triggers on it.
>
> Christoph Dalitz
On Tuesday 26 November 2002 05:09, Andy Samuel wrote: > Anybody has 7.2.3 rpms for RH 8.0 ? see ftp://ftp.postgresql.org/binary/v7.2.3/RPMS/redhat-8.0 My ISP is having severe difficulties with their core cisco 7200 right now, and my connection is popping up and down like a yoyo -- I was connected to upload them Tuesday when it went down. And it stayed down a long time, and is still not stable. I needed to move our mailserver to a more recent server anyway at that time, as well as updating DNS, etc, which I did. This involved an IP address change for the mailserver due to many factors. So, I am not getting pgsql list mail due in part to this outage -- our mailserver's IP address has been changed. After all the DNS caches clear things will be better. Well, I'll have a couple of thousand back messages, but that's not a big deal, as long as I didn't get unsubscribed to the lists in the mean time (most of my other mail resumed right away -- but the postgresql.org mailserver (relay1.pgsql.com in particular) still has the old mail.wgcr.org address in place. So it's jsut a matter of latency. :-) (no, our border router (cisco 2514 w/ IOS 12.0) doesn't do static PAT, unfortunately, or it wouldn't be a problem) While I'm at it, I want to apologize for the delay in getting RPMs out for 7.3. There are a large number of changes in the build, and due to my fourth child's birth back in October I really haven't had the spare time to do this set justice. I expect to be able to spend some quality time with the RPMset this weekend. So I might have something for Monday or Tuesday. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11