From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: Deferrable unique constraints |
Date: | 2009-07-07 22:19:20 |
Message-ID: | 1247005160.26589.290.camel@monkey-cat.sm.truviso.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-07 22:29:10 | Re: *_collapse_limit, geqo_threshold |
Previous Message | Tom Lane | 2009-07-07 22:17:20 | Re: 8.4, One-Time Filter and subquery ( ... FROM function() union all ... ) |