Re: WIP: Deferrable unique constraints

On Tue, 2009-07-14 at 15:00 -0400, Alvaro Herrera wrote:
> My 2c on this issue: if this is ugly (and it is) and needs revisiting to
> extend it, please by all means let's make it not ugly instead of moving
> the ugliness around. I didn't read the original proposal in detail so
> IMBFOS, but it doesn't seem like using our existing deferred constraints
> to handle uniqueness checks unuglifies this code enough ... For example
> I think we'd like to support stuff like "UPDATE ... SET a = -a" where
> the table is large.

I don't entirely understand what you're suggesting.

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 ;)

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?

Regards,
Jeff Davis