Re: Isolation / Visibility inside a trigger - Mailing list pgsql-general

From Jorge Godoy
Subject Re: Isolation / Visibility inside a trigger
Date
Msg-id 87zmb8ljy0.fsf@ieee.org
Whole thread Raw
In response to Re: Isolation / Visibility inside a trigger  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
Martijn van Oosterhout <kleptog@svana.org> writes:

> On Fri, Nov 03, 2006 at 10:24:21AM -0300, Jorge Godoy wrote:
>> But then, the answer to my question is that even inside the same transaction
>> or receiving the NEW row those functions called by the trigger shouldn't see
>> the information.  Did I get it right?
>
> Correct. Before triggers happen prior to the backend even attampting to
> insert. AIUI it happens before uniqueness checks, check constraints,
> foreign key checks, etc. As far as anything else in the system is
> concerned, the row does not exist yet.
>
> If it's just the flag field that's being updated, perhaps you could
> split the flags and result field into a seperate table updated by the
> after trigger.
>
> Hope this helps,

It does, thanks.


What I decided doing is creating more auxiliary functions and changing the
signature of my existing functions.  Then I'll have:

    - new functions to work with existing data, SELECTing information and

    - calling existing functions that will receive *ALL* needed information
      from the actual process output as INPUT parameters instead of trying to
      get it inside of them

My code will call these modified existing functions while using triggers
inside the database and I'll expose the new functions for external
applications.

I'll just have to document both functions so that their output / input is in
synch to make the "magic" work. :-)

Not too much work, but boring on the maintenance/documentation side.


Thanks again.

--
Jorge Godoy      <jgodoy@gmail.com>


Attachment

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Isolation / Visibility inside a trigger
Next
From: Richard Troy
Date:
Subject: Re: Counting records in a PL/pgsql cursor