2009/7/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.
And you'll be moving the ereport() back into the btree code? Makes
sense, provided that nothing is ever going to care whether the index
actually inserted an entry. I can see arguments for making the
recommended return value for "other cases" either TRUE or FALSE, but I
guess it doesn't matter since nothing is going to check it.
> For non-unique indexes, it is not required that <function>aminsert</>
> do anything; it might for instance refuse to index NULLs.
Doesn't this comment apply equally to unique indexes?
In response to
pgsql-hackers by date
|Next:||From: Brendan Jurd||Date: 2009-07-29 09:46:29|
|Subject: Re: WIP: to_char, support for EEEE format|
|Previous:||From: Dean Rasheed||Date: 2009-07-29 08:07:07|
|Subject: Re: WIP: Deferrable unique constraints|