-statement>, this expands to SQL which, itself, cannot be 'disabled'.
-
-The spec is a large one and I didn't look at all references to triggers --
-since there are hundreds -- but I don't believe that there is any
-precedent for an implementation of DISABLE TRIGGER.
-
-FWIW, i think that in the case of deferred triggers they should all be
-added to the queue and whether they are executed or not should be
-evaluated inside DeferredTriggerExecute() with:
-
- if(LocTriggerData.tg_trigger->tgenabled == false)
- return;
-
-Gavin
-
-
-
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g7D4Sgk27162
- for
; Tue, 13 Aug 2002 00:28:42 -0400 (EDT)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id 94BDB475EFD; Tue, 13 Aug 2002 00:28:37 -0400 (EDT)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id C912A475EDF; Tue, 13 Aug 2002 00:28:36 -0400 (EDT)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 0026B475924
- for
; Tue, 13 Aug 2002 00:28:30 -0400 (EDT)-Received: from sss.pgh.pa.us (unknown [192.204.191.242])
- by postgresql.org (Postfix) with ESMTP id 5263B47582B
- for
; Tue, 13 Aug 2002 00:28:30 -0400 (EDT)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g7D4SJVk022192;
- Tue, 13 Aug 2002 00:28:19 -0400 (EDT)
-To: Gavin Sherry
-Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
-Comments: In-reply-to Gavin Sherry
- message dated "Tue, 13 Aug 2002 14:12:15 +1000"
-Date: Tue, 13 Aug 2002 00:28:19 -0400
-From: Tom Lane
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: OR
-
-Gavin Sherry writes:
-> ...The spec is a large one and I didn't look at all references to triggers --
-> since there are hundreds -- but I don't believe that there is any
-> precedent for an implementation of DISABLE TRIGGER.
-
-Thanks for the dig. I was hoping we could get some guidance from the
-spec, but it looks like not. How about other implementations --- does
-Oracle support disabled triggers? DB2? etc?
-
-> FWIW, i think that in the case of deferred triggers they should all be
-> added to the queue and whether they are executed or not should be
-> evaluated inside DeferredTriggerExecute() with:
-> if(LocTriggerData.tg_trigger->tgenabled == false)
-> return;
-
-So check the state at execution, not when the triggering event occurs.
-I don't have any strong reason to object to that, but I have a gut
-feeling that it still needs to be thought about...
-
-Let's see, I guess there are several possible changes of state for a
-deferred trigger between the triggering event and the end of
-transaction:
-
-* Trigger deleted. Surely the trigger shouldn't be executed, but should
-we raise an error or just silently ignore it? (I suspect right now we
-crash :-()
-
-* Trigger created. In some ideal world we might think that such a
-trigger should be fired, but in reality that ain't gonna happen; we're
-not going to record every possible event on the speculation that some
-trigger for it might be created later in the transaction.
-
-* Trigger disabled. Your proposal is to not fire it. Okay, comports
-with the deleted case, if we make that behavior be silently-ignore.
-
-* Trigger enabled. Your proposal is to fire it. Seems not to comport
-with the creation case --- does that bother anyone?
-
-* Trigger changed from not-deferred to deferred. If we already fired it
-for the event, we surely shouldn't fire it again. I believe the code
-gets this case right.
-
-* Trigger changed from deferred to not-deferred. As Neil was pointing
-out recently, this really should cause the trigger to be fired for the
-pending event immediately, but we don't get that right at the moment.
-(I suppose a stricter interpretation would be to raise an error because
-we can't do anything that really comports with the intended behavior
-of either case.)
-
-How do these various cases relate? Can we come up with a unified
-rationale?
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://archives.postgresql.org
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g7D4usk27855
- for
; Tue, 13 Aug 2002 00:56:54 -0400 (EDT)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id F09AE475EFD; Tue, 13 Aug 2002 00:56:49 -0400 (EDT)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id 94E4B475DC0; Tue, 13 Aug 2002 00:56:47 -0400 (EDT)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 4EB5D475751
- for
; Tue, 13 Aug 2002 00:56:42 -0400 (EDT)-Received: from joeconway.com (unknown [63.210.180.150])
- by postgresql.org (Postfix) with ESMTP id A5F35475531
- for
; Tue, 13 Aug 2002 00:56:41 -0400 (EDT)-Received: from [192.168.5.2] (account jconway HELO joeconway.com)
- by joeconway.com (CommuniGate Pro SMTP 3.5.9)
- with ESMTP-TLS id 1246425; Mon, 12 Aug 2002 21:46:29 -0700
-Date: Mon, 12 Aug 2002 21:56:01 -0700
-From: Joe Conway
-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
-X-Accept-Language: en-us, en
-MIME-Version: 1.0
-To: Tom Lane
-cc: Gavin Sherry ,
-Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
-Content-Type: text/plain; charset=us-ascii; format=flowed
-Content-Transfer-Encoding: 7bit
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: OR
-
-Tom Lane wrote:
-> Gavin Sherry writes:
->>...The spec is a large one and I didn't look at all references to triggers --
->>since there are hundreds -- but I don't believe that there is any
->>precedent for an implementation of DISABLE TRIGGER.
->
-> Thanks for the dig. I was hoping we could get some guidance from the
-> spec, but it looks like not. How about other implementations --- does
-> Oracle support disabled triggers? DB2? etc?
-
-Oracle does for sure. With a complex app (i.e. Oracle Applications)
-being able to disable triggers from time-to-time is *indispensable*. Not
-sure about DB2. My knowledge of MSSQL is getting dated, but as of MSSQL7
-I don't *think* you can disable a trigger.
-
-Joe
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://archives.postgresql.org
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g7D5afk29468
- for
; Tue, 13 Aug 2002 01:36:41 -0400 (EDT)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id C40B3476088; Tue, 13 Aug 2002 01:36:42 -0400 (EDT)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id AAB02476037; Tue, 13 Aug 2002 01:36:41 -0400 (EDT)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 15911475751
- for
; Tue, 13 Aug 2002 01:36:37 -0400 (EDT)-Received: from linuxworld.com.au (www.linuxworld.com.au [203.34.46.50])
- by postgresql.org (Postfix) with ESMTP id BC813475531
- for
; Tue, 13 Aug 2002 01:36:35 -0400 (EDT)-Received: from localhost (swm@localhost)
- by linuxworld.com.au (8.11.4/8.11.4) with ESMTP id g7D5coN26796;
- Tue, 13 Aug 2002 15:38:50 +1000
-Date: Tue, 13 Aug 2002 15:38:50 +1000 (EST)
-From: Gavin Sherry
-To: Tom Lane
-Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: ORr
-
-On Tue, 13 Aug 2002, Tom Lane wrote:
-
-> Gavin Sherry writes:
-> > ...The spec is a large one and I didn't look at all references to triggers --
-> > since there are hundreds -- but I don't believe that there is any
-> > precedent for an implementation of DISABLE TRIGGER.
->
-> Thanks for the dig. I was hoping we could get some guidance from the
-> spec, but it looks like not. How about other implementations --- does
-> Oracle support disabled triggers? DB2? etc?
-
-Oracle 8 (and I presume 9) allows you to disable/enable triggers through
-alter table and alter trigger. My 8.1.7 documentation is silent on the
-cases you mention below and I do not have an oracle installation handy to
-test. Anyone?
-
->
-> > FWIW, i think that in the case of deferred triggers they should all be
-> > added to the queue and whether they are executed or not should be
-> > evaluated inside DeferredTriggerExecute() with:
-> > if(LocTriggerData.tg_trigger->tgenabled == false)
-> > return;
->
-> So check the state at execution, not when the triggering event occurs.
-> I don't have any strong reason to object to that, but I have a gut
-> feeling that it still needs to be thought about...
->
-> Let's see, I guess there are several possible changes of state for a
-> deferred trigger between the triggering event and the end of
-> transaction:
->
-> * Trigger deleted. Surely the trigger shouldn't be executed, but should
-> we raise an error or just silently ignore it? (I suspect right now we
-> crash :-()
->
-> * Trigger created. In some ideal world we might think that such a
-> trigger should be fired, but in reality that ain't gonna happen; we're
-> not going to record every possible event on the speculation that some
-> trigger for it might be created later in the transaction.
-
-It doesn't need to be an ideal world. We're only talking about deferred
-triggers after all. Why couldn't CreateTrgger() just have a look through
-deftrig_events, check for its relid and if its in there, call
-deferredTriggerAddEvent().
-
-> * Trigger disabled. Your proposal is to not fire it. Okay, comports
-> with the deleted case, if we make that behavior be silently-ignore.
->
-> * Trigger enabled. Your proposal is to fire it. Seems not to comport
-> with the creation case --- does that bother anyone?
->
-> * Trigger changed from not-deferred to deferred. If we already fired it
-> for the event, we surely shouldn't fire it again. I believe the code
-> gets this case right.
-
-Agreed.
-
-> * Trigger changed from deferred to not-deferred. As Neil was pointing
-> out recently, this really should cause the trigger to be fired for the
-> pending event immediately, but we don't get that right at the moment.
-> (I suppose a stricter interpretation would be to raise an error because
-> we can't do anything that really comports with the intended behavior
-> of either case.)
-
-I think this should generate an error as it doesn't sit well with the
-spec IMHO.
-
-Gavin
-
-
----------------------------(end of broadcast)---------------------------
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gAQ8kio01351
- for
; Tue, 26 Nov 2002 03:46:44 -0500 (EST)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id 8EB404760F9; Tue, 26 Nov 2002 03:46:13 -0500 (EST)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id B1942475FCE; Tue, 26 Nov 2002 03:46:06 -0500 (EST)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 950CD474E53
- for
; Tue, 26 Nov 2002 03:45:30 -0500 (EST)-Received: from hera.hs-niederrhein.de (hera.hs-niederrhein.de [194.94.120.3])
- by postgresql.org (Postfix) with ESMTP id 4E172474E44
- for
; Tue, 26 Nov 2002 03:45:29 -0500 (EST)-Received: (from root@localhost)
- by hera.hs-niederrhein.de (8.11.6+Sun/8.11.6) id gAQ8jTK27063
-Received: from terra (31-094.hs-niederrhein.de [193.175.48.94])
- by hera.hs-niederrhein.de (8.11.6+Sun/8.11.6) with SMTP id gAQ8jPP27051
- for
; Tue, 26 Nov 2002 09:45:25 +0100 (CET)-Date: Tue, 26 Nov 2002 09:43:32 +0100
-From: Christoph Dalitz
-Subject: [GENERAL] ALTER TRIGGER DISABLE/ENABLE
-X-Mailer: Sylpheed version 0.6.6 (GTK+ 1.2.8; i586-pc-linux-gnu)
-MIME-Version: 1.0
-Content-Type: text/plain; charset=US-ASCII
-Content-Transfer-Encoding: 7bit
-X-Virus-Scanned: by AMaViS perl-11
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: ORr
-
-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
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://archives.postgresql.org
-
-Return-path:
-Received: from beamish.nsd.ca (IDENT:root@[205.150.156.194])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gAQJg2P06491
- for
; Tue, 26 Nov 2002 14:42:04 -0500 (EST)-Received: (from smap@localhost)
- by beamish.nsd.ca (8.9.3/8.9.3) id OAA28217;
- Tue, 26 Nov 2002 14:41:56 -0500
-X-Authentication-Warning: beamish.nsd.ca: smap set sender to using -f
-Received: from reddog.nsd.ca(192.168.101.30) by beamish.nsd.ca via smap (V2.1/2.1+anti-relay+anti-spam)
- id xma028213; Tue, 26 Nov 02 14:41:31 -0500
-Received: from nsd.ca (jllachan-linux.nsd.ca [192.168.101.148])
- by reddog.nsd.ca (8.8.7/8.8.7) with ESMTP id OAA22894;
- Tue, 26 Nov 2002 14:40:22 -0500
-Date: Tue, 26 Nov 2002 14:41:47 -0500
-From: Jean-Luc Lachance
-X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-31 i686)
-X-Accept-Language: en
-MIME-Version: 1.0
-cc: Christoph Dalitz ,
-Subject: Re: [GENERAL] ALTER TRIGGER DISABLE/ENABLE
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-Status: OR
-
-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
-> + 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
-
-Return-path:
-Received: from hera.hs-niederrhein.de (hera.hs-niederrhein.de [194.94.120.3])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gAS8ZLP06871
- for
; Thu, 28 Nov 2002 03:35:23 -0500 (EST)-Received: (from root@localhost)
- by hera.hs-niederrhein.de (8.11.6+Sun/8.11.6) id gAS8ZGZ16207;
- Thu, 28 Nov 2002 09:35:16 +0100 (CET)
-Received: from pc03230 (pc03230.kr.hs-niederrhein.de [194.94.121.230])
- by hera.hs-niederrhein.de (8.11.6+Sun/8.11.6) with SMTP id gAS8ZDP16199;
- Thu, 28 Nov 2002 09:35:13 +0100 (CET)
-Date: Thu, 28 Nov 2002 09:33:57 +0100
-From: Christoph Dalitz
-To: Jean-Luc Lachance
-Subject: Re: ALTER TRIGGER DISABLE/ENABLE
-Organization: FH Niederrhein
-X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu)
-MIME-Version: 1.0
-Content-Type: text/plain; charset=US-ASCII
-Content-Transfer-Encoding: 7bit
-X-Virus-Scanned: by AMaViS perl-11
-Status: OR
-
-On Tue, 26 Nov 2002 14:41:47 -0500
-Jean-Luc Lachance 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
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gASG4EP11817
- for
; Thu, 28 Nov 2002 11:04:15 -0500 (EST)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id 0E622476313; Thu, 28 Nov 2002 11:03:52 -0500 (EST)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id 153FF476713; Thu, 28 Nov 2002 11:03:36 -0500 (EST)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 4A4AA475E41
- for
; Thu, 28 Nov 2002 11:03:19 -0500 (EST)-Received: from beamish.nsd.ca (unknown [205.150.156.194])
- by postgresql.org (Postfix) with ESMTP id 30F56475AFF
- for
; Thu, 28 Nov 2002 11:03:18 -0500 (EST)-Received: (from smap@localhost)
- by beamish.nsd.ca (8.9.3/8.9.3) id LAA12283;
- Thu, 28 Nov 2002 11:02:54 -0500
-X-Authentication-Warning: beamish.nsd.ca: smap set sender to using -f
-Received: from reddog.nsd.ca(192.168.101.30) by beamish.nsd.ca via smap (V2.1/2.1+anti-relay+anti-spam)
- id xma012273; Thu, 28 Nov 02 11:02:35 -0500
-Received: from nsd.ca (jllachan-linux.nsd.ca [192.168.101.148])
- by reddog.nsd.ca (8.8.7/8.8.7) with ESMTP id LAA00966;
- Thu, 28 Nov 2002 11:01:23 -0500
-Date: Thu, 28 Nov 2002 11:03:09 -0500
-From: Jean-Luc Lachance
-X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-31 i686)
-X-Accept-Language: en
-MIME-Version: 1.0
-To: Christoph Dalitz
-Subject: Re: [GENERAL] ALTER TRIGGER DISABLE/ENABLE
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: OR
-
-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 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
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g865JY225103
- for
; Fri, 6 Sep 2002 01:19:35 -0400 (EDT)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id 15A1C475B47; Fri, 6 Sep 2002 01:19:37 -0400 (EDT)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id 5D8C9475FC5; Fri, 6 Sep 2002 01:19:33 -0400 (EDT)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 50F2C475E88
- for
; Fri, 6 Sep 2002 01:19:29 -0400 (EDT)-Received: from houston.familyhealth.com.au (unknown [203.59.48.253])
- by postgresql.org (Postfix) with ESMTP id 633FA4759E8
- for
; Fri, 6 Sep 2002 01:19:27 -0400 (EDT)-Received: (from root@localhost)
- by houston.familyhealth.com.au (8.11.6/8.11.6) id g865JQh24183
-Received: from mariner (mariner.internal [192.168.0.101])
- by houston.familyhealth.com.au (8.11.6/8.9.3) with SMTP id g865JPk24139
- for
; Fri, 6 Sep 2002 13:19:25 +0800 (WST)-From: "Christopher Kings-Lynne"
-Subject: [HACKERS] Foreign keys in pg_dump
-Date: Fri, 6 Sep 2002 13:19:44 +0800
-Message-ID:
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Content-Transfer-Encoding: 7bit
-X-Priority: 3 (Normal)
-X-MSMail-Priority: Normal
-X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
-X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
-Importance: Normal
-X-scanner: scanned by Inflex 0.1.5c - (http://www.inflex.co.za/)
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: OR
-
-OK,
-
-The argument about using ALTER TABLE/ADD FOREIGN KEY in dumps was that it
-caused an actual check of the data in the table, right? This was going to
-be much slower than using CREATE CONSTRAINT TRIGGER.
-
-So, why can't we do this in the SQL that pg_dump creates (TODO):
-
-CREATE TABLE ...
-ALTER TABLE/ADD FOREIGN KEY ...
-update catalogs and disable triggers that the ADD FOREIGN KEY just created
-...
-COPY .. FROM ...
-\.
-update catalogs and enable triggers
-
-Doesn't this give us the best of both worlds? ie. Keeps dependencies but
-does fast COPYing?
-
-Also, I think a new super-user (or owner) only SQL command would be nice
-(TODO):
-
-ALTER TABLE foo {DISABLE|ENABLE} TRIGGER { ALL | trigger_name [ ,... ] };
-
-This is like MSSQL syntax (IIRC):
-
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_
-aa-az_3ied.asp
-Specifies that trigger_name is enabled or disabled. When a trigger is
-disabled it is still defined for the table; however, when INSERT, UPDATE, or
-DELETE statements are executed against the table, the actions in the trigger
-are not performed until the trigger is re-enabled.
-
-
-It would certainly tidy up the dumps a bit...
-
-Chris
-
-
----------------------------(end of broadcast)---------------------------
-
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g86DYQ201524
- for
; Fri, 6 Sep 2002 09:34:26 -0400 (EDT)-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP
- id C0CA0476E5C; Fri, 6 Sep 2002 09:34:19 -0400 (EDT)
-Received: from postgresql.org (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with SMTP
- id C788C476A92; Fri, 6 Sep 2002 09:34:16 -0400 (EDT)
-Received: from localhost (postgresql.org [64.49.215.8])
- by postgresql.org (Postfix) with ESMTP id 5CD18475EF0
- for
; Fri, 6 Sep 2002 09:34:12 -0400 (EDT)-Received: from squire.barchord.com (squire.barchord.com [216.194.67.18])
- by postgresql.org (Postfix) with ESMTP id 2A0AB476EAE
- for
; Fri, 6 Sep 2002 09:34:11 -0400 (EDT)-Received: from [10.0.2.49] (nat.inquent.com [216.6.14.45])
- by squire.barchord.com (Postfix) with ESMTP
- id D4B60415; Fri, 6 Sep 2002 09:34:14 -0400 (EDT)
-Subject: Re: [HACKERS] Foreign keys in pg_dump
-From: Rod Taylor
-To: Christopher Kings-Lynne
-In-Reply-To:
-References:
-Content-Type: text/plain
-Content-Transfer-Encoding: 7bit
-X-Mailer: Ximian Evolution 1.0.8
-Date: 06 Sep 2002 09:34:21 -0400
-Message-ID: <1031319261.3555.9.camel@jester>
-MIME-Version: 1.0
-X-Virus-Scanned: by AMaViS new-20020517
-Precedence: bulk
-X-Virus-Scanned: by AMaViS new-20020517
-Status: ORr
-
-On Fri, 2002-09-06 at 01:19, Christopher Kings-Lynne wrote:
-> OK,
->
-> The argument about using ALTER TABLE/ADD FOREIGN KEY in dumps was that it
-> caused an actual check of the data in the table, right? This was going to
-> be much slower than using CREATE CONSTRAINT TRIGGER.
->
-> So, why can't we do this in the SQL that pg_dump creates (TODO):
->
-> CREATE TABLE ...
-> ALTER TABLE/ADD FOREIGN KEY ...
-> update catalogs and disable triggers that the ADD FOREIGN KEY just created
-> ...
-> COPY .. FROM ...
-> \.
-> update catalogs and enable triggers
-
-The problem with this is you may enable a trigger that was disabled by
-the user. It cannot be done to all triggers. We could figure out which
-triggers were created for the foreign key via pg_depend, then re-enable
-only those.
-
-If we did most of this in a single transaction it should be fairly safe.
-
-> Doesn't this give us the best of both worlds? ie. Keeps dependencies but
-> does fast COPYing?
->
-> Also, I think a new super-user (or owner) only SQL command would be nice
-> (TODO):
->
-> ALTER TABLE foo {DISABLE|ENABLE} TRIGGER { ALL | trigger_name [ ,... ] };
-
-pg_dump shouldn't need to know that a trigger is involved for foreign
-keys. A SET CONSTRAINTS DISABLED would be more appropriate in a binary
-mode dump -- but I firmly believe that text mode dumps should run full
-checks on the data to ensure the user didn't muck with it.
-
-
-
-
----------------------------(end of broadcast)---------------------------
-
projects / postgresql.git / commitdiff