Re: update table with suppress_redundant_updates_trigger()

From: wambacher(at)posteo(dot)de
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: update table with suppress_redundant_updates_trigger()
Date: 2019-02-26 09:10:30
Message-ID: 45ae5825-0f5c-c9d1-412b-1e4d89149ad3@posteo.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Problem "solved".

"found" will be true of false depending on the trigger action.

update done -> found = true, update not done -> found=false.

But: The trigger sometimes allows updates where no data has been
changed! That is another problem to be solved :(

Regards

walter

Am 25.02.19 um 19:42 schrieb wambacher(at)posteo(dot)de:
>
> Hi,
>
> i'm doing a lot of updates in my database, but most of them are not
> necessary at all (sorry, just detected it)
>
> Therefore i installed a trigger to minimize real updates.
>
> create trigger suppress_redundant_updates_boundaries
>    before update on boundaries
>    for each row execute procedure suppress_redundant_updates_trigger();
>
> Is there a way to get the count of the real table updates?
>
> Using pl/pgsql i'm updating boundaries  with
>
>                   update boundaries
>                      set id             = bT2.id,
>                          country        = bT2.country,
>                          type           = 'admin',   
>                          value          = bT2.value,
> ...
>                         ,qm             = bT2.qm
>                         ,lwqm           =
> st_area(geography(coalesce(xlandarea,rT.way)))
>                    where id = bT2.id;
>
>                    if (found) then
>                       if (debug > 0) then raise notice 'real db update
> of % done 2', bT2.id; end if;
>                       updatedDB := updatedDB + 1;
>                    end if;
>
> i get a "wrong" result, because "found" is always true, even when the
> records are identical (hope so) and an update should be suppressed by
> the trigger.
>
> Question: will "found" be set when update has been blocked by the
> trigger - or does that not matter?
>
> if "found" is always true: what else can i do?
>
> regards
>
> walter
>
> --
> My projects:
>
> Admin Boundaries of the World <https://wambachers-osm.website/boundaries>
> Missing Boundaries
> <https://wambachers-osm.website/index.php/projekte/internationale-administrative-grenzen/missing-boundaries>
> Emergency Map <https://wambachers-osm.website/emergency>
> Postal Code Map (Germany only) <https://wambachers-osm.website/plz>
> Fools (QA for zipcodes in Germany) <https://wambachers-osm.website/fools>
> Postcode Boundaries of Germany
> <https://wambachers-osm.website/pcoundaries>
--
My projects:

Admin Boundaries of the World <https://wambachers-osm.website/boundaries>
Missing Boundaries
<https://wambachers-osm.website/index.php/projekte/internationale-administrative-grenzen/missing-boundaries>
Emergency Map <https://wambachers-osm.website/emergency>
Postal Code Map (Germany only) <https://wambachers-osm.website/plz>
Fools (QA for zipcodes in Germany) <https://wambachers-osm.website/fools>
Postcode Boundaries of Germany <https://wambachers-osm.website/pcoundaries>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mike Yeap 2019-02-26 09:37:23 Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes
Previous Message Thomas Munro 2019-02-26 08:11:54 Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes