From: | John DeSoi <desoi(at)pgedit(dot)com> |
---|---|
To: | Geoffrey Myers <lists(at)serioustechnology(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: disable triggers using psql |
Date: | 2011-02-17 13:04:20 |
Message-ID: | 93F7A907-3DF6-4E8F-B300-BD711FF83A11@pgedit.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Feb 17, 2011, at 6:59 AM, Geoffrey Myers wrote:
>> Unless something very big changed when I wasn't looking, the
>> constraints are actually implemented as triggers under the hood. But
>> you're right that it'd be cleaner to drop the constraints and re-add
>> them than to fool with system triggers.
>
> We were trying to accomplish this without having to hack the dump to much. We attempted adding:
>
> set local session_replication_role = replica;
>
> But that does not seem provide the expected relief.
If your triggers have some simple way of identifying them in a query on pg_trigger, the function below can be altered to easily enable or disable them.
John DeSoi, Ph.D.
=====
create or replace function enable_link_clean_triggers(p_enable boolean)
returns void as $$
declare
v_action text;
v_sql text;
v_tg record;
begin
if p_enable then
v_action = ' ENABLE TRIGGER ';
else
v_action = ' DISABLE TRIGGER ';
end if;
for v_tg in select tgrelid, tgname from pg_trigger where tgname ~ '^tg_link_clean_.+' loop
v_sql = 'ALTER TABLE ' || v_tg.tgrelid::regclass::text || v_action || v_tg.tgname || ';';
execute v_sql;
end loop;
return;
end;
$$ language plpgsql;
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Mead | 2011-02-17 13:32:27 | Re: Tablespace Issue |
Previous Message | Geoffrey Myers | 2011-02-17 11:59:37 | Re: disable triggers using psql |