On 9/13/19 8:07 PM, Judy Loomis wrote:
> At the very least that note about this behavior should be highlighted,
> probably on the Trigger Behavior page and not buried in a bunch of notes
> on the Create Trigger page.
I know this after the fact. Still, as a general rule the best place to
start when learning about a command is on it's respective page under here:
https://www.postgresql.org/docs/11/sql-commands.html
Further I usually go to the Notes after reading the synopsis, as Notes
is where the exceptions to the rules and gotchas are called out.
>
>
>
> On Fri, Sep 13, 2019 at 4:03 PM Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
> Judy Loomis <hoodie.judy@gmail.com <mailto:hoodie.judy@gmail.com>>
> writes:
> > I'm going to have to really look at all my BEFORE UPDATE triggers
> and make
> > sure we're not missing any more.
> > And I have to stop telling management that a trigger means we
> always know
> > when a value changes.
>
> Well, you can rely on that, just not like this. Use an AFTER trigger
> (else, you can't be sure it fires after all the BEFORE triggers)
> and instead of triggering it with a column parameter, have it do
> something like "if old.col is distinct from new.col".
>
> Yeah, it's a bit slower that way, but there's no free lunch,
> especially if you don't trust your other triggers. (Although,
> if you have so many triggers that that's a problem, I think you
> might have some other design issues.)
>
> regards, tom lane
>
>
>
> --
>
> ----------------------------------------------------------
> *Judy Loomis*
> 469.235.5839
--
Adrian Klaver
adrian.klaver@aklaver.com
