From: Jan Wieck <janwieck@yahoo.com>
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Stef Telford <stef@chronozon.artofdns.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Triggers and System Tables.
Date: Tue, 28 May 2002 10:35:11 -0400 (EDT)
Message-ID: <200205281435.g4SEZBQ17976@saturn.janwieck.net> (raw)
In-Reply-To: <20020527232423.W18114-100000@megazone23.bigpanda.com>
Stephan Szabo wrote:
>
> 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.
You're right. All the pg_stat* relations are views, and are
NOT up to date to the millisecond.
>
> > 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.
Part of it is permissions. A normal user does not (and should
not) have a right to modify system catalogs through regular
queries, but CREATE TABLE has to modify them. The direct heap
access inside the utility function is the permission override
mechanism here, and that does not invoke triggers or any rule
rewriting.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: janwieck@yahoo.com, sszabo@megazone23.bigpanda.com, stef@chronozon.artofdns.com
Subject: Re: Triggers and System Tables.
In-Reply-To: <200205281435.g4SEZBQ17976@saturn.janwieck.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox