From pgsql-patches-owner+M4639@postgresql.org Wed Aug 7 12:11:04 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g77GB3Y20812 for ; Wed, 7 Aug 2002 12:11:03 -0400 (EDT) Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 8C371475A2C; Wed, 7 Aug 2002 12:10:56 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id E46514759AD; Wed, 7 Aug 2002 12:10:54 -0400 (EDT) Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id B54944759AD for ; Wed, 7 Aug 2002 12:10:46 -0400 (EDT) Received: from klamath.dyndns.org (CPE002078144ae0.cpe.net.cable.rogers.com [24.102.202.35]) by postgresql.org (Postfix) with ESMTP id 37F70475813 for ; Wed, 7 Aug 2002 12:10:46 -0400 (EDT) Received: from boston.klamath.dyndns.org (unknown [192.168.40.12]) by klamath.dyndns.org (Postfix) with ESMTP id C76C17010; Wed, 7 Aug 2002 12:10:50 -0400 (EDT) To: Bruce Momjian cc: Tom Lane , Elliot Lee , pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints References: <200206140507.g5E57om04338@candle.pha.pa.us> From: Neil Conway In-Reply-To: <200206140507.g5E57om04338@candle.pha.pa.us> Date: 07 Aug 2002 12:10:10 -0400 Message-ID: <87it2mfy59.fsf@klamath.dyndns.org> Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-patches-owner@postgresql.org X-Virus-Scanned: by AMaViS new-20020517 Status: OR Bruce Momjian writes: > Tom Lane wrote: > > Elliot Lee writes: > > > About as obscure a bug as you can get - without the patch, disabled > > > triggers for deferred constraints get run anyways. The patch is simple and > > > works, but the "right" (and more complicated) fix may involve not adding > > > the trigger to event->dte_item to begin with. > > > > I remember looking at this issue and not doing anything because I > > couldn't decide whether the test for enabled status should occur when > > the trigger is queued or when it is executed --- or, perhaps, both? > > Is there anything in the standard about it? > > Was there any agreement on this? Any update on this? Cheers, Neil -- Neil Conway PGP Key ID: DB3C29FC ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-patches-owner+M4641@postgresql.org Wed Aug 7 12:46:40 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g77GkeY23704 for ; Wed, 7 Aug 2002 12:46:40 -0400 (EDT) Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 2162C475C7A; Wed, 7 Aug 2002 12:46:35 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id E9A4B475C29; Wed, 7 Aug 2002 12:46:32 -0400 (EDT) Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 9CACC475C29 for ; Wed, 7 Aug 2002 12:46:22 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 09669475BB7 for ; Wed, 7 Aug 2002 12:46:22 -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 g77GkNVk016878; Wed, 7 Aug 2002 12:46:23 -0400 (EDT) To: Neil Conway cc: Bruce Momjian , Elliot Lee , pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints In-Reply-To: <87it2mfy59.fsf@klamath.dyndns.org> References: <200206140507.g5E57om04338@candle.pha.pa.us> <87it2mfy59.fsf@klamath.dyndns.org> Comments: In-reply-to Neil Conway message dated "07 Aug 2002 12:10:10 -0400" Date: Wed, 07 Aug 2002 12:46:23 -0400 Message-ID: <16877.1028738783@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-patches-owner@postgresql.org X-Virus-Scanned: by AMaViS new-20020517 Status: OR Neil Conway writes: > Elliot Lee writes: > About as obscure a bug as you can get - without the patch, disabled > triggers for deferred constraints get run anyways. The patch is simple and > works, but the "right" (and more complicated) fix may involve not adding > the trigger to event->dte_item to begin with. > > I remember looking at this issue and not doing anything because I > couldn't decide whether the test for enabled status should occur when > the trigger is queued or when it is executed --- or, perhaps, both? > Is there anything in the standard about it? >> >> Was there any agreement on this? > Any update on this? I think we're still waiting for someone to figure out what the behavior should be per spec. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org From nconway@klamath.dyndns.org Wed Aug 7 14:10:27 2002 Return-path: Received: from klamath.dyndns.org (identsucks@CPE002078144ae0.cpe.net.cable.rogers.com [24.102.202.35]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g77IAQY29959 for ; Wed, 7 Aug 2002 14:10:26 -0400 (EDT) Received: from boston.klamath.dyndns.org (unknown [192.168.40.12]) by klamath.dyndns.org (Postfix) with ESMTP id 284B87010; Wed, 7 Aug 2002 14:10:21 -0400 (EDT) To: Tom Lane cc: Bruce Momjian , Elliot Lee , pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints References: <200206140507.g5E57om04338@candle.pha.pa.us> <87it2mfy59.fsf@klamath.dyndns.org> <16877.1028738783@sss.pgh.pa.us> From: Neil Conway In-Reply-To: <16877.1028738783@sss.pgh.pa.us> Date: 07 Aug 2002 14:09:40 -0400 Message-ID: <874re6fsm3.fsf@klamath.dyndns.org> Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: OR Tom Lane writes: > Neil Conway writes: > > Elliot Lee writes: > > I remember looking at this issue and not doing anything because I > > couldn't decide whether the test for enabled status should occur when > > the trigger is queued or when it is executed --- or, perhaps, both? > > Is there anything in the standard about it? [...] > I think we're still waiting for someone to figure out what the behavior > should be per spec. I took a brief look at SQL99, but I couldn't find anything regarding this issue (AFAICS it doesn't mention "disabled triggers" at all). But given my prior track record for divining information from the standards, perhaps someone should double-check :-) I did notice some behavior which we don't implement AFAIK: If the constraint mode is /deferred/, then the constraint is effectively checked when the constraint mode is changed to /immediate/ either explicitely by execution of a , or implicitely at the end of the current SQL-transaction. (SQL99, Section 4.17.1, paragraph 3) We don't recheck any outstanding deferred constraints when the constraint mode is explicitly switched back to IMMEDIATE, as the standard says we should. Cheers, Neil -- Neil Conway PGP Key ID: DB3C29FC From pgsql-patches-owner+M4751@postgresql.org Tue Aug 13 00:10:31 2002 Return-path: Received: from postgresql.org (postgresql.org [64.49.215.8]) by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g7D4AVk26779 for ; Tue, 13 Aug 2002 00:10:31 -0400 (EDT) Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 321AE475A20; Tue, 13 Aug 2002 00:10:26 -0400 (EDT) Received: from postgresql.org (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with SMTP id 7BB7E475F42; Tue, 13 Aug 2002 00:10:20 -0400 (EDT) Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id A0519476087 for ; Tue, 13 Aug 2002 00:10:10 -0400 (EDT) Received: from linuxworld.com.au (www.linuxworld.com.au [203.34.46.50]) by postgresql.org (Postfix) with ESMTP id 70806475806 for ; Tue, 13 Aug 2002 00:09:57 -0400 (EDT) Received: from localhost (swm@localhost) by linuxworld.com.au (8.11.4/8.11.4) with ESMTP id g7D4CGI23801; Tue, 13 Aug 2002 14:12:16 +1000 Date: Tue, 13 Aug 2002 14:12:15 +1000 (EST) From: Gavin Sherry To: Neil Conway cc: pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints In-Reply-To: <874re6fsm3.fsf@klamath.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-patches-owner@postgresql.org X-Virus-Scanned: by AMaViS new-20020517 Status: OR On 7 Aug 2002, Neil Conway wrote: > Tom Lane writes: > > Neil Conway writes: > > > Elliot Lee writes: > > > I remember looking at this issue and not doing anything because I > > > couldn't decide whether the test for enabled status should occur when > > > the trigger is queued or when it is executed --- or, perhaps, both? > > > Is there anything in the standard about it? > > [...] > > > I think we're still waiting for someone to figure out what the behavior > > should be per spec. > > I took a brief look at SQL99, but I couldn't find anything regarding > this issue (AFAICS it doesn't mention "disabled triggers" at all). But > given my prior track record for divining information from the > standards, perhaps someone should double-check :-) I had a pretty hard look around SQL99. It does not appear to say anything explicit about disabling triggers. This should be clear from page 90: 4.35 Triggers. This specifies the trigger descriptor. Those familiar with SQL99 know that it just about mandates that all state information about any object in the system is recorded in its descriptor. The fact that enabled/disabled state information is not recorded in the trigger descriptor suggests that it is only ever enabled. More over there is no case when a trigger is not executed, according to 10.12 'Execution of triggers'. I dug deeper, wondering if it may be implicitly disabled given the disabling of its 'dependencies', shall we call them. Namely: the base table or the procedure used in the trigger action. Tables cannot be disabled or made in active. As for the procedure, , 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 (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) From pgsql-patches-owner+M4752@postgresql.org Tue Aug 13 00:28:42 2002 Return-path: 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 cc: Neil Conway , pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints In-Reply-To: References: 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 Message-ID: <22191.1029212899@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-patches-owner@postgresql.org 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 From pgsql-patches-owner+M4753@postgresql.org Tue Aug 13 00:56:55 2002 Return-path: 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 Message-ID: <3D589161.8020903@joeconway.com> 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 , Neil Conway , pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints References: <22191.1029212899@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-patches-owner@postgresql.org 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 From pgsql-patches-owner+M4755@postgresql.org Tue Aug 13 01:36:42 2002 Return-path: 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 cc: Neil Conway , pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints In-Reply-To: <22191.1029212899@sss.pgh.pa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-patches-owner@postgresql.org 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)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-general-owner+M33538@postgresql.org Tue Nov 26 03:46:45 2002 Return-path: 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 for pgsql-general@postgresql.org; Tue, 26 Nov 2002 09:45:29 +0100 (CET) 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 To: pgsql-general@postgresql.org Subject: [GENERAL] ALTER TRIGGER DISABLE/ENABLE Message-ID: <20021126094332.58250aef.christoph.dalitz@hs-niederrhein.de> 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 Sender: pgsql-general-owner@postgresql.org 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 From jllachan@nsd.ca Tue Nov 26 14:42:05 2002 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 Sender: jllachan@reddog.nsd.ca Message-ID: <3DE3CE7B.614EE99E@nsd.ca> 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 To: Bruce Momjian cc: Christoph Dalitz , pgsql-general@postgresql.org Subject: Re: [GENERAL] ALTER TRIGGER DISABLE/ENABLE References: <200211261853.gAQIrdE00304@candle.pha.pa.us> 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 > 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 From christoph.dalitz@hs-niederrhein.de Thu Nov 28 03:35:25 2002 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 cc: Bruce Momjian , Tino Wildenhain , pgsql-general@postgresql.org Subject: Re: ALTER TRIGGER DISABLE/ENABLE Message-ID: <20021128093357.48c9d644.christoph.dalitz@hs-niederrhein.de> In-Reply-To: <3DE3CE7B.614EE99E@nsd.ca> References: <200211261853.gAQIrdE00304@candle.pha.pa.us> <3DE3CE7B.614EE99E@nsd.ca> 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 From pgsql-general-owner+M33790@postgresql.org Thu Nov 28 11:04:17 2002 Return-path: 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 Message-ID: <3DE63E3D.5BC92720@nsd.ca> 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 cc: Bruce Momjian , Tino Wildenhain , pgsql-general@postgresql.org Subject: Re: [GENERAL] ALTER TRIGGER DISABLE/ENABLE References: <200211261853.gAQIrdE00304@candle.pha.pa.us> <3DE3CE7B.614EE99E@nsd.ca> <20021128093357.48c9d644.christoph.dalitz@hs-niederrhein.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-general-owner@postgresql.org 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 From pgsql-hackers-owner+M28358@postgresql.org Fri Sep 6 01:19:36 2002 Return-path: 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 for pgsql-hackers@postgresql.org; Fri, 6 Sep 2002 13:19:26 +0800 (WST) (envelope-from chriskl@familyhealth.com.au) 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" To: "Hackers" 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 Sender: pgsql-hackers-owner@postgresql.org 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)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org From pgsql-hackers-owner+M28381@postgresql.org Fri Sep 6 09:34:27 2002 Return-path: 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 cc: Hackers 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 Sender: pgsql-hackers-owner@postgresql.org 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)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org