Re: WIP: Deferrable unique constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: Deferrable unique constraints
Date: 2009-07-28 23:00:51
Message-ID: 10509.1248822051@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Another thought on the index AM API issues: after poking through the
code I realized that there is *nobody* paying any attention to the
existing bool result of aminsert() (ie, did we insert anything or not).
So I think that instead of adding a bool* parameter, we should repurpose
the function result, along the lines of this spec:

<para>
The method's boolean result value is significant only when
<literal>checkUnique</> is <literal>UNIQUE_CHECK_PARTIAL</>.
In this case a TRUE result means the new entry is known unique, whereas
FALSE means it might be non-unique (and a deferred uniqueness check must
be scheduled). For other cases a constant FALSE result is recommended.
</para>

<para>
For non-unique indexes, it is not required that <function>aminsert</>
do anything; it might for instance refuse to index NULLs.
</para>

The bool* parameter is fairly ugly in a couple of ways: it's not clear
when it's okay to pass a NULL pointer, and the compiler doesn't give
you a lot of help in being sure you've set the result in all code paths.
So I'd rather not use one if we don't have to.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mike Rylander 2009-07-28 23:20:20 Re: xpath not a good replacement for xpath_string
Previous Message Tom Lane 2009-07-28 21:40:20 Re: Deferred uniqueness versus foreign keys