Re: Multi-row constraints, how to avoid unnecessary trigger execution? - Mailing list pgsql-general

From Sándor Daku
Subject Re: Multi-row constraints, how to avoid unnecessary trigger execution?
Date
Msg-id CAKyoTgZbC0yRfHNgB5sHgbvneLD=resXp82qdRX2iEq=Yce5WA@mail.gmail.com
Whole thread Raw
In response to Multi-row constraints, how to avoid unnecessary trigger execution?  (Tobia Conforto <tobia.conforto@gruppo4.eu>)
Responses Re: Multi-row constraints, how to avoid unnecessary trigger execution?
List pgsql-general
On 6 April 2016 at 18:32, Tobia Conforto <tobia.conforto@gruppo4.eu> wrote:
I have a complex data validation requirement that spans many rows and possibly more than one table.

The application must be able to perform several data manipulation statements that could invalidate the requirement between one another, and only have the database check this requirement at transaction commit time.

Ideally I would have some sort of after trigger that is deferred to commit time, have it search for invalid or missing records and raise errors if any is found.

If I'm reading the manual correctly, the only kind of trigger that can be deferred to commit time is a constraint trigger. The problem is that this trigger must be declared for each row, but I need to only perform the validation once per transaction, because it executes complex queries.

What is the best way to address this issue?

Is there any other way, other than a constraint trigger, to defer execution of a piece of code at transaction commit time?

Otherwise, can I check for repeated invocations of my trigger function in the same transaction and return early on the second and following ones? I could do that by creating a temporary table on commit drop, but it seems overkill. Is there a lighter solution?

-Tobia

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

 
Are you continuously feeding data to the db via the app during the transaction or working on data which is already in the database?
In the second case you can write a db side function which can do the work, validate and commit or rollback at the end.

Regards,
Sándor  
  

pgsql-general by date:

Previous
From: Tobia Conforto
Date:
Subject: Multi-row constraints, how to avoid unnecessary trigger execution?
Next
From: Andreas Joseph Krogh
Date:
Subject: Re: Multi-row constraints, how to avoid unnecessary trigger execution?