Re: WIP: Deferrable unique constraints

Jeff Davis wrote:

> The only problem there is telling the btree AM whether or not to do the
> insert or not (i.e. fake versus real insert). Perhaps you can just do
> that with careful use of a global variable?
> 
> Sure, all of this is a little ugly, but we've already acknowledged that
> there is some ugliness around the existing unique constraint and the
> btree code that supports it (for one, the btree AM accesses the heap).

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.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.