From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Laurent Wandrebeck" <l(dot)wandrebeck(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Column level triggers |
Date: | 2008-10-15 00:16:57 |
Message-ID: | dcc563d10810141716x67e30aacu56ad1c5f03db2e6c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Mon, Oct 13, 2008 at 3:44 AM, Laurent Wandrebeck
<l(dot)wandrebeck(at)gmail(dot)com> wrote:
> Hi,
>
> According to the documentation (
> http://www.postgresql.org/docs/8.3/interactive/sql-createtrigger.html
> ), the feaure "SQL allows triggers to fire on updates to specific
> columns (e.g., AFTER UPDATE OF col1, col2)" is missing.
> After a bit of research, I found that this feature was in the TODO
> list ( http://wiki.postgresql.org/wiki/Todo#Triggers ), and that a
> patch was proposed on 2005/07.
> Is it going to be implemented soon ? It would greatly help, IMHO, for
> load, and simplify the write of plpgsql functions called by before
> triggers.
> Regards, and keep up the good work, that DBMS (mostly;) rocks !
You'll probably have to ask that in -hackers. I'm guessing it's one
of those things that if one wrote a sufficiently large check one could
find a hacker to implement it. But I can't imagine it being a weekend
project, and if it's not already in 8.4 beta it wouldn't make it to
8.4, but you'd have to shoot for 8.5.
Since you can check which columns have changed, it's pretty easy to
write a trigger that just skips its logic when none of the trigger
columns have changed.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-10-15 00:21:06 | Re: Drupal and PostgreSQL - performance issues? |
Previous Message | Chris | 2008-10-15 00:15:34 | Re: Drupal and PostgreSQL - performance issues? |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-10-15 00:29:28 | Re: minimal update |
Previous Message | Tom Lane | 2008-10-15 00:11:30 | Re: Improving planner variable handling |