Re: TRUNCATE question

I agree it matches the description. That said, it rather surprised me
when Triggers and things didn't go off. Primarily due to the 'Works
like a Delete *'. The description has changed since I first
discovered it though.
--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.

----- Original Message -----
From: "Mike Mascari" <mascarm(at)mascari(dot)com>
To: "Rod Taylor" <rbt(at)barchord(dot)com>
Cc: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>; "Hackers"
<pgsql-hackers(at)postgresql(dot)org>
Sent: Thursday, August 02, 2001 10:40 PM
Subject: Re: [HACKERS] TRUNCATE question

> Rod Taylor wrote:
> >
> > Makes for a real pain when the nice and safe foreign keys aren't
> > really nice and safe anymore.
> > >
> > > It's supposed to work that way - same as Oracle.
>
> TRUNCATE TABLE is essentially short-hand for DROP/CREATE, but
preserves
> GRANT permissions, associations from its oid in functions, views,
etc.
> Oracle disallows TRUNCATE on a table involved in a referential
integrity
> relationship, but doesn't disallow the behavior for a normal ON
DELETE
> trigger. According to previous discussions, PostgreSQL should behave
> similarly. If it does not, its a bug. I haven't checked the status
since
> 7.1.0, so I don't know.
>
> Accordingly, as of 7.1.0, nothing stops you in PostgreSQL from
> performing a DROP/CREATE on a table involved in a referential
integrity
> relationship. Now your foreign keys are completely gone. I haven't
> checked that behavior in later versions, however. Oracle requires
DROP
> TABLE <table> CASCADE CONSTRAINTS to force a DROP of a table
involved in
> a primary/foreign key relationship.
>
> Mike Mascari
> mascarm(at)mascari(dot)com
>