First, I'm happy that you're working on this; I think it's important. I am working on another index constraints feature that may have some interaction:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php Let me know if you see any potential conflicts between our work. On Tue, 2009-07-07 at 19:38 +0100, Dean Rasheed wrote: > For potential uniqueness violations a > deferred trigger is queued to do a full check at the end of the > statement or transaction, or when SET CONSTRAINTS is called. The > trigger then replays the insert in a "fake insert" mode, which doesn't > actually insert anything - it just checks that what is already there > is unique, waiting for other transactions if necessary. What does the deferred trigger do? Do you need a "fake insert" mode or can you use an index search instead? I'm thinking that you could just store the TID of the tuple that causes the potential violation in your list. Then, when you recheck the list, for each potential violation, find the tuple from the TID, do a search using the appropriate attributes, and if you get multiple results there's a conflict. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
