From 89f4f4a8e558e7a830486e30414c0ceeaa876362 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Mon, 26 Aug 2002 20:03:10 +0000 Subject: [PATCH] Add info on disabled triggers. --- doc/TODO.detail/trigger | 553 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 553 insertions(+) create mode 100644 doc/TODO.detail/trigger diff --git a/doc/TODO.detail/trigger b/doc/TODO.detail/trigger new file mode 100644 index 0000000000..16cf6fae13 --- /dev/null +++ b/doc/TODO.detail/trigger @@ -0,0 +1,553 @@ +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 + -- GitLab