Re: Problems with disabling triggers in Postgres 7.3.9

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

In response to

Browse pgsql-sql by date

  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