Re: Triggers and System Tables. - Mailing list pgsql-sql

From Jan Wieck
Subject Re: Triggers and System Tables.
Date
Msg-id 200205281435.g4SEZBQ17976@saturn.janwieck.net
Whole thread Raw
In response to Re: Triggers and System Tables.  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List 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
throughregular   queries, but CREATE TABLE has to modify them. The direct heap   access inside the utility function is
thepermission 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 #




pgsql-sql by date:

Previous
From: schaefer@alphanet.ch
Date:
Subject: Re: Some additional PostgreSQL questions
Next
From: Tom Lane
Date:
Subject: Re: Some additional PostgreSQL questions