Re: Table AM Interface Enhancements

Поиск
Список
Период
Сортировка
От Pavel Borisov
Тема Re: Table AM Interface Enhancements
Дата
Msg-id CALT9ZEH+8XWxCVcjf7Hm0eH+z7-TrvHOxnr7ndscDSA90T+2cQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Table AM Interface Enhancements  (Pavel Borisov <pashkin.elfe@gmail.com>)
Ответы Re: Table AM Interface Enhancements  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
Hi, Alexander!

The other extensibility that seems quite clear and uncontroversial to me is 0006.

It simply shifts the decision on whether tuple inserts should invoke inserts to the related indices to the table am level. It doesn't change the current heap insert behavior so it's safe for the existing heap access method. But new table access methods could redefine this (only for tables created with these am's) and make index inserts independently of ExecInsertIndexTuples inside their own implementations of tuple_insert/tuple_multi_insert methods.  

I'd propose changing the comment:

1405  * This function sets `*insert_indexes` to true if expects caller to return
1406  * the relevant index tuples.  If `*insert_indexes` is set to false, then
1407  * this function cares about indexes itself.

in the following way

Tableam implementation of tuple_insert should set `*insert_indexes` to true
if it expects the caller to insert the relevant index tuples (as in heap
 implementation). It should set `*insert_indexes` to false if it cares 
about index inserts itself and doesn't want the caller to do index inserts.

Maybe, a commit message is also better to reformulate to describe better who should do what.

I think, with rebase and correction in the comments/commit message patch 0006 is ready to be committed.

Regards,
Pavel Borisov.

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Add new error_action COPY ON_ERROR "log"
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Table AM Interface Enhancements