From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
---|---|
To: | Willy-Bas Loos <willybas(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: implicit transaction changes trigger behaviour |
Date: | 2019-08-29 13:21:20 |
Message-ID: | CAKoxK+4bKcrHU+S3MHeW_KPGGP_E75L0oFeDCECUtnNfzCsYzw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Aug 29, 2019 at 2:16 PM Willy-Bas Loos <willybas(at)gmail(dot)com> wrote:
> delete from b;
> --DELETE 3
Here the trigger is fired 3 times (for each row), and on every single
test it finds a row in 'a', that is your variable n_b_type1 is always
1, that causes the trigger (fired on each row) to not abort. If you
delete first the row that makes the trigger fail, you will not be able
to do the deletion happen outside an explicit transaction:
testdb=# delete from b where type = 1;
DELETE
testdb=# delete from b;
ERROR: Each record of a must have exactly 1 corresponding records in
b of type 1. But after this delete the a-record with id 5 would have 0
b-records of type 1, so the operation has been cancelled.
So it seems to me a problem within the trigger: when executing outside
the transaction your row is deleted as last, and this makes the
deletion "iterate" and remove all the rows. Within the transaction,
when the trigger fires, no rows are there, so it fails. Either this is
what you have to do or your query within the trigger is wrong.
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-08-29 13:35:35 | Re: implicit transaction changes trigger behaviour |
Previous Message | Day, David | 2019-08-29 13:04:25 | RE: Rename a column if not already renamed.? |