Re: TRUNCATE - Mailing list pgsql-hackers

From Joel Burton
Subject Re: TRUNCATE
Date
Msg-id JGEPJNMCKODMDHGOBKDNKENLCNAA.joel@joelburton.com
Whole thread Raw
In response to Re: TRUNCATE  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
> -----Original Message-----
> From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au]
> Sent: Sunday, May 12, 2002 10:17 PM
> To: Joel Burton; Tom Lane; Rod Taylor
> Cc: Hackers List
> Subject: RE: [HACKERS] TRUNCATE
>
>
> > I'm happy w/o the FORCE option (just let TRUNCATE do it), but if enough
> > people think that the FORCE keyword should be added to allow
> overriding of
> > triggers, that could be a good compromise.
> >
> > But, please, don't take away the ability to TRUNCATE. Doing it
> when there
> > are triggers is one the strengths of TRUNCATE, IMNSHO.
>
> It seems to me that there's more and more need for an 'SET CONSTRAINTS
> DISABLED' and 'SET CONSTRAINTS ENABLED' command that affects only foreign
> keys.  This would basically make it ignore foreign key checks for the
> remainder of the transaction.  This could be used before a
> TRUNCATE command,
> and would also be essential when we switch to dumping ALTER TABLE/FOREIGN
> KEY commands in pg_dump, and we don't want them to be checked...

This would be different than SET CONSTRAINTS DEFERRED, in that DISABLED
would never perform the checks, even at the end of the transaction?

- J.

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant



pgsql-hackers by date:

Previous
From: "Joel Burton"
Date:
Subject: Re: TRUNCATE
Next
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: TRUNCATE