Re: WIP: Deferrable unique constraints

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

In response to

Responses

Browse pgsql-hackers by date

  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 ... )