Re: Triggers on columns

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: "KaiGai Kohei" <kaigai(at)ak(dot)jp(dot)nec(dot)com>, "Itagaki Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Triggers on columns
Date: 2009-09-03 14:45:29
Message-ID: 4A9F9039020000250002AA1C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> It also seems to me logically inconsistent that we would expose this
> information via the CREATE TRIGGER interface but not to the trigger
> function itself. From within the function, you can compare NEW and
> OLD, but you get no visibility into which columns were actually
> updated. And apparently now from within CREATE TRIGGER we'll have
> just the opposite. Blech...

Sybase provides an "if update(columnname)" syntax to allow such tests.
Perhaps PostgreSQL could do something similar?

> Sometimes it's useful to schedule a no-op update explicitly for the
> purpose of firing triggers.

Yes. It's a less frequent need, but it does exist. The thing is, if
you only fire triggers if something was actually changed to a new
value, you can't get to that. If you fire on all updates you can test
whether there were actual changes. Of course, ideally, both would be
convenient.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2009-09-03 14:55:38 Re: Triggers on columns
Previous Message Peter Eisentraut 2009-09-03 14:37:38 Re: Triggers on columns