Re: WIP: Deferrable unique constraints

Jeff Davis wrote:

> 1. Are you saying that an AM API change is the best route? If so, we
> should probably start a discussion along those lines. Heikki is already
> changing the API for index-only scans, and Dean's API change proposal
> may be useful for Kenneth's unique hash indexes. You might as well all
> attack the current API in unison ;)

Yeah, I don't think there's any point in keeping the API stable just for
the sake of keeping it stable. I mean surely we don't want to break it
for no reason, but if we can clean up the uniqueness check situation
somehow by breaking the API, for all means let's explore that ... (I
don't think anybody likes the way btree currently abuses the heap API;
it's just that it's so damn fast to do it that way. Certainly we don't
want to make it slower!)

> 2. Even if we allow some kind of bulk constraint check to optimize the
> "set a = a + 1" case, we should still allow some much cheaper mechanism
> to defer retail constraint violations. For that, why not make use of the
> existing constraint trigger mechanism?

Sure, perhaps you're right, which is why I added the disclaimer that I
hadn't actually read the patch in any detail ...

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support