On Tue, May 5, 2015 at 10:31 AM, Andres Freund <andres@anarazel.de> wrote:
> Another thing I'm wondering about is dealing with deferrable
> constraints/deferred indexes.
>
> a) Why does ExecCheckIndexConstraints() check for indisimmediate for
> *all* indexes and not just when it's an arbiter index? That seems
> needlessly restrictive.
I guess it's a legacy of the time when it was all or nothing. But
supporting that would involve further complicating the interface with
ExecCheckIndexConstraints() so that we cared about the distinction
between conflicts for one purpose and conflicts for another. It could
be done, though.
> b) There's a doc addition to set_constraints.sgml
> + constraints are affected by this setting. Note that constraints
> + that are <literal>DEFERRED</literal> cannot be used as arbiters by
> + the <literal>ON CONFLICT</> clause that <command>INSERT</>
> + supports.
>
> which I don't think makes sense: SET CONSTRAINTS will never change
> anything relevant for ON CONFLICT, right?
You're right.
--
Peter Geoghegan