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

From Jeff Davis
Subject Re: WIP: Deferrable unique constraints
Date
Msg-id 1247005160.26589.290.camel@monkey-cat.sm.truviso.com
Whole thread Raw
In response to WIP: Deferrable unique constraints  (Dean Rasheed <dean.a.rasheed@googlemail.com>)
Responses Re: WIP: Deferrable unique constraints  (Dean Rasheed <dean.a.rasheed@googlemail.com>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.4, One-Time Filter and subquery ( ... FROM function() union all ... )
Next
From: Robert Haas
Date:
Subject: Re: *_collapse_limit, geqo_threshold