Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:

   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.

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

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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group