From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
Cc: | pgsql-general(at)postgresql(dot)org, Bruno Wolff III <bruno(at)wolff(dot)to> |
Subject: | Re: PL/pgSQL : notion of deferred execution |
Date: | 2005-12-12 15:29:28 |
Message-ID: | 2099.1134401368@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
>> It might also work for you to do this with access rights.
> Well, actually that's kinda how it's working at the moment, however I would
> rather avoid this additional dependancy on user/role since it's really
> field/situation-dependent (see below).
After reading the explanation, this seems way too specialized a
situation to make a good argument that we need a general feature
of the sort.
You can get to where you need to be by passing an indicator in
the trigger arguments, eg,
CREATE TRIGGER ... BEFORE UPDATE ... EXECUTE PROCEDURE mytrigger(0);
CREATE TRIGGER ... AFTER UPDATE ... EXECUTE PROCEDURE mytrigger(1);
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Frank van Vugt | 2005-12-12 16:16:01 | Re: PL/pgSQL : notion of deferred execution |
Previous Message | Tom Lane | 2005-12-12 15:16:49 | Re: PostGreSQL 8.1.0 : out of memory during vacuum full analyze |