Date: Mon, 27 May 2002 23:51:51 -0700 (PDT)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Stef Telford <stef@chronozon.artofdns.com>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: Triggers and System Tables.
In-Reply-To: <20020528053547.169468AEA@chronozon.artofdns.com>
Message-ID: <20020527232423.W18114-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 28 May 2002, Stef Telford wrote:

> 	> Hello,
> 	> 	this is probably a really silly question, but where can i
> 	> control wether or not the superuser/root user can create a trigger
> 	> on a system table ?
>
> 	In general this is not something you can safely do. I'm not sure if
> 	pg_stat_activity modifications go through something that will fire
> 	triggers, but in general you shouldn't expect that they will on system
> 	tables.
>

As a note, pg_stat_activity is a view and doesn't appear to be
modified directly (it looks like it gets its real info
from various functions).  And, IIRC it isn't guaranteed to be
completely up to date.

> It would make sense to assume that, even though the tables
> in question are system tables, that triggers can be used
> in unison with them. I do, of course, understand the
> inherent dangers with attaching triggers (it could
> be possible to attach a trigger that would delete user
> logins) but then, this is what i want them -for- :)
>
> The limitation would, to my untrained eye, appear to be
> completely aberant.  The ability to put triggers on
> system tables would allow me to (using plpgsql)

AFAIK many/most places that want to modify system tables don't
do normal queries to do so and as such probably won't do rule
rewriting or trigger invokations. Part of this is probably a
performance reason, part is probably the dangerousness of it
which would tend to make it probably a lower priority for anyone
to consider looking at.