Re: Clarification, please

Поиск
Список
Период
Сортировка
От Mladen Gogala
Тема Re: Clarification, please
Дата
Msg-id 4CF685B1.1040601@vmsinfo.com
обсуждение исходный текст
Ответ на Re: Clarification, please  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Clarification, please  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-novice
Tom Lane wrote:
> Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
>
>> In Oracle, deferrable primary keys are enforced by non-unique indexes.
>> That seems logical,
>>
>
> ... maybe to an Oracle guy ...
>

I humbly admit being one. I am getting used to the life without the dark
side of the force, however. I saw the light, I am saved. When the
rapture comes, I will not be left behind.  However, I still have to
maintain a rather big 4-way Oracle RAC configuration and some satellite
Oracle databases.

>
>> When the constraint is deferred in the transaction block, however, it
>> tolerates duplicate values until the end of transaction:
>>
>
> Sure.  That's exactly per spec: the check is deferred to end of
> transaction.  If the duplicated index entries are both/all still live
> at that time, you get an error.
>

I agree with you. I was only wandering how was it done with a unique index.

> We do still execute the insertion-time uniqueness check, but instead of
> throwing an error on failure, we just queue a trigger event to recheck
> that key before commit.  If the insertion-time check passes then there's
> no need for a recheck later.  This is a win because the insertion-time
> check is cheap, being integrated into the insertion process itself.
>
>             regards, tom lane
>
Thanks for a wonderful explanation. That's all I needed.

--

Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
http://www.vmsinfo.com
The Leader in Integrated Media Intelligence Solutions




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Clarification, please
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Clarification, please