From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Subject: | Re: How to fire triggers just on "top" level DML |
Date: | 2011-01-19 22:11:49 |
Message-ID: | 201101191411.49543.adrian.klaver@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wednesday 19 January 2011 1:59:48 pm Kevin Grittner wrote:
> We've been running for about ten years on a framework which fires
> triggers similar to database triggers in a Java tier close to the
> database, and we're now trying to convert these to actual PostgreSQL
> database triggers. Our biggest hitch at the moment is that we
> defined a class of triggers we called "top" triggers, which only
> fire from DML submitted by the application, not from DML issued by
> other triggers.
>
> One significant use of this is to block direct modification of
> summary data (either selected columns or entire tables) which are
> supposed to be trigger maintained. It's not immediately obvious how
> to accomplish this within PostgreSQL, although I'm probably missing
> something. We're not tied to any particular methodology -- a
> TG_DEPTH variable, if it existed, would do fine, for example.
>
> Any suggestions?
>
> -Kevin
The only thing I can think of off the top of my head is to you trigger arguments
and then use the below to test:
TG_ARGV[]
Data type array of text; the arguments from the CREATE TRIGGER statement.
The index counts from 0. Invalid indexes (less than 0 or greater than or equal
to tg_nargs) result in a null value.
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Aram Fingal | 2011-01-19 22:17:51 | Re: Group by with insensitive order |
Previous Message | akp geek | 2011-01-19 22:07:46 | ERROR: index row requires 9984 bytes, maximum size is 8191 |