Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
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 18:51:21
Message-ID: 8299.1486579881@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> 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().

> This is actually noted directly within infer_arbiter_indexes(), about
> half way down:
> * Let executor complain about !indimmediate case directly, because
> * enforcement needs to occur there anyway when an inference clause is
> * omitted.

I'm not following. If the executor needs to check too, that's fine,
but why is it okay for the planner not to check? Assume that for some
weird reason the user has both indimmediate and !indimmediate indexes
on the same column set. If the planner chooses the wrong one, don't
bad things happen? If it doesn't matter which index the planner
picks, why are we doing this at plan time at all?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2017-02-08 18:57:40 Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT
Previous Message Peter Geoghegan 2017-02-08 18:38:11 Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT