From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Decibel! <decibel(at)decibel(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Truncate Triggers |
Date: | 2008-02-02 22:38:40 |
Message-ID: | 24984.1201991920@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> On Sat, Feb 02, 2008 at 05:23:39PM -0500, Christopher Browne wrote:
>> I think it would be nice to be able to have more "trigger hooks"
>> relating to DDL changes, but I also think that will represent some
>> fundamentally more difficult problems being raised than is the case
>> for a TRUNCATE trigger.
> Are they really?
One fairly obvious difficulty is how to pass the trigger any meaningful
information about what happened (or is about to happen). In the case of
TRUNCATE, pretty much everything you need to know is implicit in the
event type.
I suspect that triggers on DDL will also share some of the problems
we've identified in past discussions about supporting triggers on system
catalogs --- in fact, to a first approximation these might be the same
thing. It's not clear that we want to be firing random user-defined
code during the process of a catalog update, nor that it can be
guaranteed a consistent view of the system state. TRUNCATE triggers
are a narrow enough case to dodge that complexity, or much of it anyway
(in a multi-table TRUNCATE there'd still be some interesting questions
about just when the triggers fire).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2008-02-02 23:13:57 | Re: <IDLE> and waiting |
Previous Message | Tom Lane | 2008-02-02 22:28:50 | Re: <IDLE> and waiting |