Re: PL/pgSQL : notion of deferred execution - Mailing list pgsql-general

From Tom Lane
Subject Re: PL/pgSQL : notion of deferred execution
Date
Msg-id 17168.1134319479@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/pgSQL : notion of deferred execution  (Bruno Wolff III <bruno@wolff.to>)
Responses Re: PL/pgSQL : notion of deferred execution
List pgsql-general
Bruno Wolff III <bruno@wolff.to> writes:
> On Sun, Dec 11, 2005 at 16:31:59 +0100,
>   Frank van Vugt <ftm.van.vugt@foxi.nl> wrote:
>> Ratio: when deferred triggers on table A are used to calculate field values of
>> table B (which then obviously need an update), one might want to prevent
>> direct updates on these fields of table B

> It might also work for you to do this with access rights. The triggers can
> have different access rights than the user that caused the trigger to fire.

Yes.  Keying this off whether the triggers are deferred or not seems
a fairly bizarre choice --- that's surely not the primary property that
should determine what they can do to table B.  Also, it's quite unclear
which part of the system you expect to enforce the restriction against
which other part.  The suggestion as stated seemed to be to let a
trigger find out whether it itself is being fired in a deferred fashion,
but surely you don't want to trust the trigger to decide whether it may
update B.

            regards, tom lane

pgsql-general by date:

Previous
From: Douglas McNaught
Date:
Subject: Re: [SQL] Looking for information on PostgreSQL Stored Procedures
Next
From: "Foster, Stephen"
Date:
Subject: Re: [SQL] Looking for information on PostgreSQL Stored Procedures