Re: Triggers and System Tables.

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: Stef Telford <stef(at)chronozon(dot)artofdns(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: Triggers and System Tables.
Date: 2002-05-28 14:35:11
Message-ID: 200205281435.g4SEZBQ17976@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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(at)Yahoo(dot)com #

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2002-05-28 14:38:06 Re: Some additional PostgreSQL questions
Previous Message Sandeep Chibber 2002-05-28 09:11:02 Problem with the result set of postgres