In article <4b5702b9.50...@postnewspapers.com.au>,
Craig Ringer writes:
>> What'd be the behavior of a (plpgsql) trigger function when called as
>> a statement level trigger?
>> Let's say that a statement will involve more than one row.
>> The documentation (v8.4.2, "35.1. Overview of Trigger Beh
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> What'd be the behavior of a (plpgsql) trigger function when called as
> a statement level trigger?
> Let's say that a statement will involve more than one row.
> The documentation (v8.4.2, "35.1. Overview of Trigger Behavior") says:
>
> "State
Vincenzo Romano wrote:
> Hi all.
>
> What'd be the behavior of a (plpgsql) trigger function when called as
> a statement level trigger?
> Let's say that a statement will involve more than one row.
> The documentation (v8.4.2, "35.1. Overview of Trigger Behavior") says:
>
> "Statement-level trigge
Hi all.
What'd be the behavior of a (plpgsql) trigger function when called as
a statement level trigger?
Let's say that a statement will involve more than one row.
The documentation (v8.4.2, "35.1. Overview of Trigger Behavior") says:
"Statement-level triggers do not currently have any way to exa
It's true, PostgreSQL can only check a unique contraint at the time the
row is inserted and can't defer it to the end of the statement due to
the way they are implemented (using the indexes). Sure, there has been
talk about it but I don't think anyone has done it yet.
The thing is that for the vas
> This has nothing to do with triggers, it has to do with not being able
> to defer UNIQUE constraints. The classic solution is:
>
> update SET column = -column;
> update SET column = -column+1;
Thanks for the reply.
Is changing query the only way to do this in postgres?
I would expect some mor
