From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Flávio Suguimoto <flavio(dot)suguimoto(at)pragyatechnologies(dot)com> |
Cc: | "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Problems with disabling triggers in Postgres 7.3.9 |
Date: | 2006-03-09 15:50:12 |
Message-ID: | 25361.1141919412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
=?iso-8859-1?Q?Fl=E1vio_Suguimoto?= <flavio(dot)suguimoto(at)pragyatechnologies(dot)com> writes:
> EXECUTE ''update pg_class set reltriggers = count(*) from pg_trigger where
> pg_class.oid=tgrelid and relname = '' || quote_literal(tablename);
This command is just plain wrong, because the aggregation is done across
uncertain scope. Something like
update pg_class set reltriggers = (select count(*) from pg_trigger where
pg_class.oid=tgrelid)
where relname = 'foo'
would at least not run the risk of assigning wrong counts. You still
have the issue that the commands will touch every table with a given
name; there needs to be some thought about schemas here.
In general though I agree with Alvaro's comment that touching system
catalogs directly is bad practice. You should update to a PG version
that has ALTER TABLE DISABLE TRIGGER, and use that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2006-03-10 12:19:30 | Set generating functions and subqueries |
Previous Message | Flávio Suguimoto | 2006-03-09 15:11:14 | Re: Problems with disabling triggers in Postgres 7.3.9 |