On Tue, May 5, 2015 at 10:31 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
