database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-31 10:30:33 +03:00
Code Activity
Files
5495e607d01a858561ea2cc138e272a667c128e3
postgres/doc/TODO.detail/trigger
Bruce Momjian 07d89f6f81 Add to TODO: 
* With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY

Add to trigger TODO.detail.
2003-05-24 01:28:22 +00:00

993 lines
41 KiB
Plaintext
Raw Blame History

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
From pgsql-general-owner+M33538@postgresql.org Tue Nov 26 03:46:45 2002
Return-path: <pgsql-general-owner+M33538@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 gAQ8kio01351
for <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <pgsql-general@postgresql.org>; 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 <pgsql-general@postgresql.org>; Tue, 26 Nov 2002 09:45:25 +0100 (CET)
Date: Tue, 26 Nov 2002 09:43:32 +0100
From: Christoph Dalitz <christoph.dalitz@hs-niederrhein.de>
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: <jllachan@nsd.ca>
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 <pgman@candle.pha.pa.us>; 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 <jllachan@nsd.ca> 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 <jllachan@nsd.ca>
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 <pgman@candle.pha.pa.us>
cc: Christoph Dalitz <christoph.dalitz@hs-niederrhein.de>,
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: <christoph.dalitz@hs-niederrhein.de>
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 <pgman@candle.pha.pa.us>; 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 <christoph.dalitz@hs-niederrhein.de>
To: Jean-Luc Lachance <jllachan@nsd.ca>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Tino Wildenhain <tino@wildenhain.de>, 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 <jllachan@nsd.ca> wrote:
>
> I think thte sintax should be:
>
> ALTER TABLE DISABLE|ENABLE TRIGGER {trigger name}|ALL
>
This would make no sense:
It could be the syntax if the statement for creating a trigger
where "ALTER TABLE ADD TRIGGER".
The statement for creating a trigger is however "CREATE TRIGEER".
Consequently the statement for changing a trigger must be "ALTER TRIGGER"
and not "ALTER TABLE".
Switching off all triggers for an individual table at once would be
convenient of course and can be easily achieved with "ALTER TRIGGER" as well:
just write a little PL/SQL procedure "disable_triggers()" that takes a
tablename as input and disables all triggers on it.
Christoph Dalitz
From pgsql-general-owner+M33790@postgresql.org Thu Nov 28 11:04:17 2002
Return-path: <pgsql-general-owner+M33790@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 gASG4EP11817
for <pgman@candle.pha.pa.us>; 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 <pgsql-general@postgresql.org>; 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 <pgsql-general@postgresql.org>; 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 <jllachan@nsd.ca> 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 <jllachan@nsd.ca>
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 <christoph.dalitz@hs-niederrhein.de>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Tino Wildenhain <tino@wildenhain.de>, 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 <jllachan@nsd.ca> wrote:
> >
> > I think thte sintax should be:
> >
> > ALTER TABLE DISABLE|ENABLE TRIGGER {trigger name}|ALL
> >
> This would make no sense:
>
> It could be the syntax if the statement for creating a trigger
> where "ALTER TABLE ADD TRIGGER".
>
> The statement for creating a trigger is however "CREATE TRIGEER".
>
> Consequently the statement for changing a trigger must be "ALTER TRIGGER"
> and not "ALTER TABLE".
>
> Switching off all triggers for an individual table at once would be
> convenient of course and can be easily achieved with "ALTER TRIGGER" as well:
> just write a little PL/SQL procedure "disable_triggers()" that takes a
> tablename as input and disables all triggers on it.
>
> Christoph Dalitz
---------------------------(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: <pgsql-hackers-owner+M28358@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 g865JY225103
for <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; Fri, 6 Sep 2002 13:19:25 +0800 (WST)
From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
To: "Hackers" <pgsql-hackers@postgresql.org>
Subject: [HACKERS] Foreign keys in pg_dump
Date: Fri, 6 Sep 2002 13:19:44 +0800
Message-ID: <GNELIHDDFBOCMGBFGEFOKEBMCEAA.chriskl@familyhealth.com.au>
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: <pgsql-hackers-owner+M28381@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 g86DYQ201524
for <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <rbt@zort.ca>
To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
cc: Hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <GNELIHDDFBOCMGBFGEFOKEBMCEAA.chriskl@familyhealth.com.au>
References: <GNELIHDDFBOCMGBFGEFOKEBMCEAA.chriskl@familyhealth.com.au>
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
View Git Blame Copy Permalink