| 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: | Whole Thread | Raw Message | 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 |