Re: Rule not invoked in 7.1

From: Kyle <kyle(at)actarg(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-sql(at)postgresql(dot)org, janwieck(at)yahoo(dot)com
Subject: Re: Rule not invoked in 7.1
Date: 2001-01-26 17:05:27
Message-ID: 3A71AE57.BBDFA129@actarg.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane wrote:

> Kyle <kyle(at)actarg(dot)com> writes:
> > If someone happens to know the primary key of a record they should not be
> > able to access, and they try to update it, I would like the backend to
> > ignore the query (or better yet, raise an exception but I haven't figured
> > out how to do that). If the status is correct, the update should proceed.
>
> This might be better done with a trigger than a rule. For one thing,
> a trigger can easily raise an exception. MHO is that rules are good
> when you need to update multiple rows in other tables when certain
> things happen. If you just want to validate or twiddle an individual
> tuple as it's inserted/updated, a trigger is a good bet.
>

The underlying table contains payroll data. Each employee should be able to
enter payroll
requests, but there is a very strict set of rules about which rows he should be
able to access,
how he can access them, and when.

For example, an employee can enter new time records, but once the records have
been
approved or paid, he can no longer modify them.

I have set up several views that allow access to the rows depending on their
status. For example,
employees only have access to "working records." Once they are satisfied with
the data they
have entered, they change the status to "open" at which point they can no
longer edit it.

Supervisors then have access to the record and can approve it, changing its
status to "approved"
and so on.

The problem I had with trying to use a trigger was that the trigger fires on
the underlying table,
regardless of which view the user comes in on. (At least it seemed that way
when I tested it.)
I need to apply a different set of rules based on which view the user is coming
in on--not simply
who the user is.

Is there a way to configure a trigger to fire on a view rather than the
underlying table? I tried linking
a trigger to a view but it seemed to not get called at all. I assumed this was
because the rewriting
rules were directing the query away from the view class and so the trigger was
never getting called
at all.

Attachment Content-Type Size
kyle.vcf text/x-vcard 185 bytes

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Kyle 2001-01-26 17:13:28 Re: Rule not invoked in 7.1
Previous Message Josh Berkus 2001-01-26 17:02:57 Re: abstract data types?