open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add info on disabled triggers.

Browse Source
REL7_3_STABLE
Bruce Momjian 24 years ago
parent 339982c850
commit 89f4f4a8e5
1 changed files with 553 additions and 0 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 553
      doc/TODO.detail/trigger

553
doc/TODO.detail/trigger
Unescape View File

@ -0,0 +1,553 @@
From pgsql-patches-owner+M4639@postgresql.org Wed Aug 7 12:11:04 2002
Return-path: <pgsql-patches-owner+M4639@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 g77GB3Y20812
for <pgman@candle.pha.pa.us>; 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 <pgsql-patches@postgresql.org>; 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 <pgsql-patches@postgresql.org>; 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 <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Elliot Lee <sopwith@redhat.com>,
pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
References: <200206140507.g5E57om04338@candle.pha.pa.us>
From: Neil Conway <nconway@klamath.dyndns.org>
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 <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
> > Elliot Lee <sopwith@redhat.com> 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 <neilconway@rogers.com>
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: <pgsql-patches-owner+M4641@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 g77GkeY23704
for <pgman@candle.pha.pa.us>; 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 <pgsql-patches@postgresql.org>; 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 <pgsql-patches@postgresql.org>; 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 <nconway@klamath.dyndns.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Elliot Lee <sopwith@redhat.com>,
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 <nconway@klamath.dyndns.org>
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 <tgl@sss.pgh.pa.us>
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 <nconway@klamath.dyndns.org> writes:
> Elliot Lee <sopwith@redhat.com> 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: <nconway@klamath.dyndns.org>
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 <pgman@candle.pha.pa.us>; 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 <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Elliot Lee <sopwith@redhat.com>,
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 <nconway@klamath.dyndns.org>
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 <tgl@sss.pgh.pa.us> writes:
> Neil Conway <nconway@klamath.dyndns.org> writes:
> > Elliot Lee <sopwith@redhat.com> 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 <set
constraints mode statement>, 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 <neilconway@rogers.com>
PGP Key ID: DB3C29FC
From pgsql-patches-owner+M4751@postgresql.org Tue Aug 13 00:10:31 2002
Return-path: <pgsql-patches-owner+M4751@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 g7D4AVk26779
for <pgman@candle.pha.pa.us>; 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 <pgsql-patches@postgresql.org>; 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 <pgsql-patches@postgresql.org>; 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 <swm@linuxworld.com.au>
To: Neil Conway <nconway@klamath.dyndns.org>
cc: pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
In-Reply-To: <874re6fsm3.fsf@klamath.dyndns.org>
Message-ID: <Pine.LNX.4.21.0208131342460.22771-100000@linuxworld.com.au>
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 <tgl@sss.pgh.pa.us> writes:
> > Neil Conway <nconway@klamath.dyndns.org> writes:
> > > Elliot Lee <sopwith@redhat.com> 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, <SQL procedure
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
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
From pgsql-patches-owner+M4752@postgresql.org Tue Aug 13 00:28:42 2002
Return-path: <pgsql-patches-owner+M4752@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 g7D4Sgk27162
for <pgman@candle.pha.pa.us>; 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 <pgsql-patches@postgresql.org>; 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 <pgsql-patches@postgresql.org>; 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 <swm@linuxworld.com.au>
cc: Neil Conway <nconway@klamath.dyndns.org>, pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
In-Reply-To: <Pine.LNX.4.21.0208131342460.22771-100000@linuxworld.com.au>
References: <Pine.LNX.4.21.0208131342460.22771-100000@linuxworld.com.au>
Comments: In-reply-to Gavin Sherry <swm@linuxworld.com.au>
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 <tgl@sss.pgh.pa.us>
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 <swm@linuxworld.com.au> 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: <pgsql-patches-owner+M4753@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 <pgman@candle.pha.pa.us>; 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 <pgsql-patches@postgresql.org>; 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 <pgsql-patches@postgresql.org>; 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 <mail@joeconway.com>
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 <tgl@sss.pgh.pa.us>
cc: Gavin Sherry <swm@linuxworld.com.au>,
Neil Conway <nconway@klamath.dyndns.org>, pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
References: <Pine.LNX.4.21.0208131342460.22771-100000@linuxworld.com.au> <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 <swm@linuxworld.com.au> 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: <pgsql-patches-owner+M4755@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 <pgman@candle.pha.pa.us>; 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 <pgsql-patches@postgresql.org>; 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 <pgsql-patches@postgresql.org>; 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 <swm@linuxworld.com.au>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Neil Conway <nconway@klamath.dyndns.org>, pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Fix disabled triggers with deferred constraints
In-Reply-To: <22191.1029212899@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0208131530160.25873-100000@linuxworld.com.au>
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 <swm@linuxworld.com.au> 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
Write Preview
Loading…
Cancel
Save