Re: WIP: Deferrable unique constraints

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: Deferrable unique constraints
Дата
Msg-id 10509.1248822051@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: Deferrable unique constraints  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: WIP: Deferrable unique constraints  (Dean Rasheed <dean.a.rasheed@googlemail.com>)
Список 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
itmight 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
refuseto 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Deferred uniqueness versus foreign keys
Следующее
От: Mike Rylander
Дата:
Сообщение: Re: xpath not a good replacement for xpath_string