Re: WIP: Deferrable unique constraints

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: WIP: Deferrable unique constraints
Дата
Msg-id 8e2dbb700907290122q1a5e2f2dga247c229abca9404@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Deferrable unique constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: WIP: Deferrable unique constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2009/7/29 Tom Lane <tgl@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


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

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: WIP: Deferrable unique constraints
Следующее
От: Brendan Jurd
Дата:
Сообщение: Re: WIP: to_char, support for EEEE format