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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
