From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tiago Babo <tiago(dot)babo(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT |
Date: | 2017-02-08 01:48:14 |
Message-ID: | CAH2-Wz=ui3Asb8xtY40L1jF4cxgqmnoSbmpoJT74TWSUYMz69g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Feb 7, 2017 at 5:41 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> It won't work with deferrable constraints (even when immediate
> enforcement is in effect, so obscure reasons). Enforcement occurs in
> the executor -- see ExecCheckIndexConstraints().
Note also that it needs to happen in the executor, because
infer_arbiter_indexes() may return immediately when ON CONFLICT DO
NOTHING is used without the user specifying which particular
constraint to use as an arbiter. (This is forbidden with ON CONFLICT
DO UPDATE, since it doesn't make sense to not have an arbiter in mind
there.)
This is actually noted directly within infer_arbiter_indexes(), about
half way down:
/*
* Extract info from the relation descriptor for the index. We know
* that this is a target, so get lock type it is known will ultimately
* be required by the executor.
*
* Let executor complain about !indimmediate case directly, because
* enforcement needs to occur there anyway when an inference clause is
* omitted.
*/
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | NAVEEN CHALIMETI | 2017-02-08 06:39:06 | Re: BUG #14531: server process (PID 12714) was terminated by signal 11: Segmentation fault |
Previous Message | Peter Geoghegan | 2017-02-08 01:41:31 | Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT |