Re: TRUNCATE

From: "Joel Burton" <joel(at)joelburton(dot)com>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Rod Taylor" <rbt(at)zort(dot)ca>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TRUNCATE
Date: 2002-05-13 04:14:54
Message-ID: JGEPJNMCKODMDHGOBKDNKENLCNAA.joel@joelburton.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Christopher Kings-Lynne [mailto:chriskl(at)familyhealth(dot)com(dot)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(at)joelburton(dot)com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

In response to

  • Re: TRUNCATE at 2002-05-13 02:17:07 from Christopher Kings-Lynne

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2002-05-13 04:24:22 Re: TRUNCATE
Previous Message Joel Burton 2002-05-13 04:12:15 Re: TRUNCATE