2009/7/29 Tom Lane <t...@sss.pgh.pa.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: > > <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> >
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. > <para> > For non-unique indexes, it is not required that <function>aminsert</> > do anything; it might for instance refuse to index NULLs. > </para> > Doesn't this comment apply equally to unique indexes? - Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
