Re: WIP: Deferrable unique constraints - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: WIP: Deferrable unique constraints
Date
Msg-id 20090714190014.GK4799@alvh.no-ip.org
Whole thread Raw
In response to Re: WIP: Deferrable unique constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: WIP: Deferrable unique constraints  (Jeff Davis <pgsql@j-davis.com>)
Re: WIP: Deferrable unique constraints  (Dean Rasheed <dean.a.rasheed@googlemail.com>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Synch Rep for CommitFest 2009-07
Next
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] large object does not exist after pg_migrator