From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Luca Looz <luca(dot)looz92(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: UPDATE column without FK fires other FK triggers constraint check |
Date: | 2017-07-19 18:42:07 |
Message-ID: | 8678.1500489727@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Luca Looz <luca(dot)looz92(at)gmail(dot)com> writes:
> After some tests it seems that this happens when the same row is covered by
> more than 1 update in the same transaction even without any change.
> Is this an expected behavior? Why it happens?
Yes, see comment in RI_FKey_fk_upd_check_required:
* If the original row was inserted by our own transaction, we
* must fire the trigger whether or not the keys are equal. This
* is because our UPDATE will invalidate the INSERT so that the
* INSERT RI trigger will not do anything; so we had better do the
* UPDATE check. (We could skip this if we knew the INSERT
* trigger already fired, but there is no easy way to know that.)
Although this is talking about the BEGIN; INSERT; UPDATE; COMMIT case,
the code has no way to tell that apart from BEGIN; UPDATE; UPDATE; COMMIT.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | vstuart | 2017-07-19 18:49:09 | Re: ~/.psqlrc file is ignored |
Previous Message | Jerry Sievers | 2017-07-19 18:32:11 | Re: Two-phase commit case studies |