Christopher Kings-Lynne wrote:
Yes, agreed. I think we decided that super-user-only could disable trigger on a global basis. I prevent folks from mucking with the system tables to do it.
It should be a per-table thing:
ALTER TABLE blah [ DISABLE | ENABLE ] [ALL | FOREIGN KEY ] TRIGGERS;
Doing it with "alter table" seems to imply that the change is permanent (eg, the table loses checking), whereas that is most certainly not what is wanted. With a SET variable it lasts only for the session, and doesn't have to be reset manually.
Assuming one wants the setting to last, as far as I can think of, an alter table would also mean either a) doing the aforementioned juggling with setting number of triggers to 0 and recounting when enabling or b) adding a new field to tables on the catalog. Solution a) I think is a nasty hack, and doesn't reflect the fact that the table *does* have triggers (which just happen to be disabled), whereas solution a) probably implies adding a field to tables in the catalog - and it's probably too much trouble?
On the other hand, "alter table" has the advantage of being far more intuitive. Any other comments on this?
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
