Re: Triggering from a specific column update

From: Adrian Klaver <aklaver(at)comcast(dot)net>
To: pgsql-general(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bob Pawley" <rjpawley(at)shaw(dot)ca>
Subject: Re: Triggering from a specific column update
Date: 2009-11-16 01:55:34
Message-ID: 200911151755.35183.aklaver@comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sunday 15 November 2009 5:18:20 pm Tom Lane wrote:
> "Bob Pawley" <rjpawley(at)shaw(dot)ca> writes:
> > Hope this elucidates you?
>
> No, it's all handwaving. In particular, showing only a fragment from
> a case that does work as you expect doesn't illuminate what's not
> working. Please show the whole table definition, the whole trigger,
> and the specific case that's not doing what you expect.
>
> regards, tom lane

The above would help greatly with coming to a correct answer. In the mean time
the problem seems to be that the trigger fires and inserts a row everytime it
sees a NEW.pump* value = 'True'. Since an update in Postgres is basically an
insert/delete operation everytime you update you will get back the existing
values as well as any changed values in the current update. This means if you
do sequential updates changing the pump1 to 'True',pump2 to 'True' and serial
values the trigger will keep inserting rows because the new.pump1 value will
meet the the IF condition. The way I have dealt with this is to do NEW.*/OLD.*
comparisons to determine if I am truly looking at a changed value or a recycled
one.

--
Adrian Klaver
aklaver(at)comcast(dot)net

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Smith 2009-11-16 03:16:01 Re: Voting: "pg_ctl init" versus "initdb"
Previous Message John Mitchell 2009-11-16 01:22:11 When running pgsql2shp it truncates fields that are over 10 characters. How can I prevent this from occurring?