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@xxxxxxxxxxxxx
<mailto:tgl@xxxxxxxxxxxxx>> wrote:
Judy Loomis <hoodie.judy@xxxxxxxxx <mailto:hoodie.judy@xxxxxxxxx>>
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@xxxxxxxxxxx
