--- On Wed, 1/2/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> [ pokes at it... ] The reason is that you defined both the trigger and
> the testing function as STABLE, which means that they see a snapshot of
> the database as of the start of the calling SQL command. In the first
> case that's the UPD
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> --- On Tue, 1/1/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Please provide a self-contained example.
> Basically the example demonstrates the difference a single tuple UPDATE when
> preformed the following two ways:
> UPDATE table ...; -- Sees OL
--- On Tue, 1/1/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Please provide a self-contained example.
Basically the example demonstrates the difference a single tuple UPDATE when
preformed the following two ways:
UPDATE table ...; -- Sees OLD.
BEGIN; UPDATE table ...; COMMIT; --Sees NEW.
I wa
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> However, It seems the select doesn't yet see the non-committed records. I.E.
> the record that should be equal to NEW is in fact equal to OLD.
Please provide a self-contained example.
regards, tom lane
---
I have a PLpgSQL AFTER UPDATE constraint trigger that calls a trigger function
with an embedded select statement.
The select statement queries the affected table and returns a mult-result set
that includes the record equivalent to NEW.
However, It seems the select doesn't yet see the non-commit
