From: | Jorge Pereira <jrp(at)ideiaprima(dot)com> |
---|---|
To: | PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Disabling triggers / constraints |
Date: | 2004-05-21 04:28:16 |
Message-ID: | 40AD8560.2010004@ideiaprima.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-05-21 05:09:53 | Re: Disabling triggers / constraints |
Previous Message | Christopher Kings-Lynne | 2004-05-21 03:21:13 | Re: Disabling triggers / constraints |