Re: TRUNCATE question
От | Mike Mascari |
---|---|
Тема | Re: TRUNCATE question |
Дата | |
Msg-id | 3B6A0F14.C6F76B6B@mascari.com обсуждение исходный текст |
Ответ на | TRUNCATE question ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | 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@mascari.com
В списке pgsql-hackers по дате отправления: