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
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 |