Re: TRUNCATE question

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>
Subject: Re: TRUNCATE question
Date: 2001-08-03 02:40:20
Message-ID: 3B6A0F14.C6F76B6B@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2001-08-03 02:43:47 Re: TRUNCATE question
Previous Message Rod Taylor 2001-08-03 02:11:20 Re: TRUNCATE question