Re: Triggers on columns

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

On Thu, Sep 3, 2009 at 10:37 AM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> On Thu, 2009-09-03 at 10:24 -0400, Robert Haas wrote:
>> If TRIGGER ON UPDATE OF foo_id means whether the value actually
>> changed, then I can skip the check.  If TRIGGER ON UPDATE OF foo_id
>> means whether the column was present in the update list, then it
>> doesn't.  Perhaps there are some use cases where we can be certain
>> that we only care about whether the value was in the update list, and
>> not whether it was changed, but off the top of my head it seems like
>> 0% of mine would fall into that category.
>
> Yeah, probably.  I didn't make this up; I'm just reading the
> standard. ;-)
>
> But of course you can already do what you do, so you don't lose anything
> if it turns out that this proposed feature ends up working the other
> way.

Sure, but I don't think it makes a lot of sense to spend a lot of time
implementing the standard behavior unless someone can provide a
plausible use case. If that means we have to give our non-standard
feature an incompatible syntax or whatever so as not to create
confusion with the "standard" behavior, then let's do that, because it
sounds WAY more useful.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2009-09-03 15:38:36 Re: community decision-making & 8.5
Previous Message Dimitri Fontaine 2009-09-03 14:55:38 Re: Triggers on columns